From nobody Thu Dec 3 10:24:18 2015 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6641B3524; Thu, 3 Dec 2015 10:24:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151203182416.14249.59890.idtracker@ietfa.amsl.com> Date: Thu, 03 Dec 2015 10:24:16 -0800 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-07.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 18:24:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : AES Encryption with HMAC-SHA2 for Kerberos 5 Authors : Michael J. Jenkins Michael A. Peck Kelley W. Burgin Filename : draft-ietf-kitten-aes-cts-hmac-sha2-07.txt Pages : 16 Date : 2015-12-03 Abstract: This document specifies two encryption types and two corresponding checksum types for Kerberos 5. The new types use AES in CTS mode (CBC mode with ciphertext stealing) for confidentiality and HMAC with a SHA-2 hash for integrity. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-aes-cts-hmac-sha2-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 3 10:32:46 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D5D1ACDEE for ; Thu, 3 Dec 2015 10:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_STOP=2.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tArBnE9bFINJ for ; Thu, 3 Dec 2015 10:32:42 -0800 (PST) Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) by ietfa.amsl.com (Postfix) with ESMTP id 03E951ACDC5 for ; Thu, 3 Dec 2015 10:32:42 -0800 (PST) Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 96C506C00C6 for ; Thu, 3 Dec 2015 13:32:41 -0500 (EST) Received: from imshyb01.MITRE.ORG (imshyb01.mitre.org [129.83.29.2]) by smtpvmsrv1.mitre.org (Postfix) with ESMTP id 890DD6C00B3 for ; Thu, 3 Dec 2015 13:32:41 -0500 (EST) Received: from imshyb01.MITRE.ORG (129.83.29.2) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 3 Dec 2015 13:32:41 -0500 Received: from na01-by2-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1130.7 via Frontend Transport; Thu, 3 Dec 2015 13:32:41 -0500 Received: from BY1PR09MB0869.namprd09.prod.outlook.com (10.162.144.143) by BY1PR09MB0870.namprd09.prod.outlook.com (10.162.144.144) with Microsoft SMTP Server (TLS) id 15.1.331.20; Thu, 3 Dec 2015 18:32:39 +0000 Received: from BY1PR09MB0869.namprd09.prod.outlook.com ([10.162.144.143]) by BY1PR09MB0869.namprd09.prod.outlook.com ([10.162.144.143]) with mapi id 15.01.0331.023; Thu, 3 Dec 2015 18:32:39 +0000 From: "Peck, Michael A" To: "kitten@ietf.org" Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-07.txt Thread-Index: AQHRLffhflBo6PwCuEqIaXntnmxehJ65QjiA Date: Thu, 3 Dec 2015 18:32:39 +0000 Message-ID: <8BBA724D-905D-4B7D-BE87-A8748D8A8F3E@mitre.org> References: <20151203182416.14249.59890.idtracker@ietfa.amsl.com> In-Reply-To: <20151203182416.14249.59890.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mpeck@mitre.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [192.80.55.87] x-microsoft-exchange-diagnostics: 1; BY1PR09MB0870; 5:c+jvAFjNbrHss+crCUdlkfDpCkNbWHZKJ5Ej6CVOsFzHrbrHDr04PFLEvNpWrfoQrxPUpKPVctopSqAoLZyiST0LE5XASpeC8THcpoCyEmJK3kBDfmLgg8x2SMM88m/zdjZ5bDpEdpXr/qz0Hf/pAQ==; 24:wCy6/WQ1rphZs261pANEoygQ2OFr3smfB6dDLzzhGdTAg7NfyE04iiHfmdMtHuG/JXhBqLkRyfagjlsRi2DatP77+BU+/69K/WYOGI/uKXw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR09MB0870; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:BY1PR09MB0870; BCL:0; PCL:0; RULEID:; SRVR:BY1PR09MB0870; x-forefront-prvs: 077929D941 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(164054003)(479174004)(199003)(377454003)(24454002)(189002)(377424004)(102836003)(6116002)(3846002)(586003)(76176999)(10400500002)(66066001)(105586002)(86362001)(99286002)(36756003)(54356999)(101416001)(50986999)(33656002)(11100500001)(1220700001)(83716003)(87936001)(107886002)(5001960100002)(450100001)(82746002)(97736004)(83506001)(40100003)(2501003)(81156007)(5004730100002)(2950100001)(110136002)(4001350100001)(122556002)(2900100001)(106356001)(92566002)(106116001)(5002640100001)(2351001)(77096005)(1096002)(189998001)(15975445007)(230783001)(19580405001)(5008740100001)(19580395003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR09MB0870; H:BY1PR09MB0869.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: mitre.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <4A04C489E38A824EABF6D4905414EDF1@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2015 18:32:39.4857 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR09MB0870 X-OriginatorOrg: mitre.org Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-07.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 18:32:45 -0000 SGkgLQ0KDQpXZSB3b3VsZCBhcHByZWNpYXRlIHdvcmtpbmcgZ3JvdXAgZmVlZGJhY2sgb24gdGhp cyBuZXcgZmluYWxseSBwb3N0ZWQgZHJhZnQuDQpJIGJlbGlldmUgd2XigJl2ZSBhZGRyZXNzZWQg YWxsIG9mIHRoZSBhY3Rpb24gaXRlbXMgZnJvbSBCZW7igJlzIEFwcmlsIDE3IGVtYWlsIChxdW90 ZWQgYmVsb3cpLg0KDQpXaGlsZSByZW1vdmluZyB0cnVuY2F0aW9uIGZyb20gdGhlIFBSRiBvdXRw dXQsIHdlIGFsc28gY2hhbmdlZCAod2l0aCB0aGUgZ29hbCBvZiBzaW1wbGlmeWluZykgdGhlIFBS RiBjb21wdXRhdGlvbiAoZW5kIG9mIHNlY3Rpb24gNSAvIHRvcCBvZiBwYWdlIDcpLg0KSWYgdGhl IG5ldyBjb21wdXRhdGlvbiBpc27igJl0IGRlc2lyZWQsIHBsZWFzZSBsZXQgdXMga25vdyBhbmQg d2UgY2FuIGNoYW5nZSBpdCBiYWNrLg0KDQpXZSByZS1kaWQgdGhlIGVuY3J5cHRpb24gYW5kIGNo ZWNrc3VtIHRlc3QgdmVjdG9ycyB0byB1c2UgdGhlIEtjLCBLZSwgYW5kIEtpIHZhbHVlcyBnZW5l cmF0ZWQgYnkgdGhlIGtleSBkZXJpdmF0aW9uIHRlc3QgdmVjdG9ycyBzbyB0aGF0IGFsbCB0aGUg c3RlcHMgd291bGQgYmUgc2hvd24uDQpXZSBhbHNvIGFkZGVkIHZlcmJvc2l0eSB0byB0aGUgUFJG IHRlc3QgdmVjdG9ycy4NCg0KVGhhbmtzLA0KTWlrZQ0KDQoNCk9uIDQvMTcvMjAxNSA1OjIzIFBN LCBCZW5qYW1pbiBLYWR1ayB3cm90ZToNCj5UaGF0IHNlZW1zIHRvIGxlYXZlIHVzIHdpdGggdGhl IGZvbGxvd2luZyBhY3Rpb24gaXRlbXM6DQo+Rm9yIHRoZSBkb2N1bWVudCBlZGl0b3I6DQo+KiBy ZW1vdmUgdHJ1bmNhdGlvbiBmcm9tIHRoZSBQUkYgb3V0cHV0IGFuZCB1c2UgdGhlIG5hdHVyYWwg aGFzaCBvdXRwdXQNCj5sZW5ndGgNCj4qIHJlbW92ZSB0aGUgdXNlIG9mIHJhbmRvbS10by1rZXko KSBhbmQgZGlzY3Vzc2lvbiBvZiBjb25zdGFudCB2YWx1ZXMgZnJvbQ0KPnNlY3Rpb24gMw0KPiog YWRkIGFuIG91dHB1dCBsZW5ndGggYXJndW1lbnQgdG8gS0RGLUhNQUMtU0hBMigpIGFuZCBhZGp1 c3QgdGV4dA0KPmFjY29yZGluZ2x5DQo+KiB1cGRhdGUgdGVzdCB2ZWN0b3JzIHRvIGluY2x1ZGUg YmFzZSBrZXlzIGFuZCBrZXkgdXNhZ2UgdmFsdWVzIGZvciBhbGwNCj50ZXN0IGNhc2VzDQo+KiBy ZXdvcmQgdGhlIHRleHQgZGlzY3Vzc2luZyBhZXMyNTYgd2l0aCAxOTItYml0IGtleXMNCg0KDQoN Cg0KDQpPbiAxMi8zLzE1LCAxOjI0IFBNLCAiS2l0dGVuIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmciIDxraXR0ZW4tYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3cm90ZToNCg0KPg0KPkEgTmV3IEludGVybmV0LURyYWZ0 IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmll cy4NCj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29tbW9uIEF1dGhlbnRpY2F0 aW9uIFRlY2hub2xvZ3kgTmV4dCBHZW5lcmF0aW9uIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYu DQo+DQo+ICAgICAgICBUaXRsZSAgICAgICAgICAgOiBBRVMgRW5jcnlwdGlvbiB3aXRoIEhNQUMt U0hBMiBmb3IgS2VyYmVyb3MgNQ0KPiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogTWljaGFlbCBK LiBKZW5raW5zDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBNaWNoYWVsIEEuIFBlY2sNCj4g ICAgICAgICAgICAgICAgICAgICAgICAgIEtlbGxleSBXLiBCdXJnaW4NCj4JRmlsZW5hbWUgICAg ICAgIDogZHJhZnQtaWV0Zi1raXR0ZW4tYWVzLWN0cy1obWFjLXNoYTItMDcudHh0DQo+CVBhZ2Vz ICAgICAgICAgICA6IDE2DQo+CURhdGUgICAgICAgICAgICA6IDIwMTUtMTItMDMNCj4NCj5BYnN0 cmFjdDoNCj4gICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0d28gZW5jcnlwdGlvbiB0eXBlcyBh bmQgdHdvIGNvcnJlc3BvbmRpbmcNCj4gICBjaGVja3N1bSB0eXBlcyBmb3IgS2VyYmVyb3MgNS4g IFRoZSBuZXcgdHlwZXMgdXNlIEFFUyBpbiBDVFMgbW9kZQ0KPiAgIChDQkMgbW9kZSB3aXRoIGNp cGhlcnRleHQgc3RlYWxpbmcpIGZvciBjb25maWRlbnRpYWxpdHkgYW5kIEhNQUMgd2l0aA0KPiAg IGEgU0hBLTIgaGFzaCBmb3IgaW50ZWdyaXR5Lg0KPg0KPg0KPlRoZSBJRVRGIGRhdGF0cmFja2Vy IHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYta2l0dGVuLWFlcy1jdHMtaG1hYy1zaGEyLw0KPg0KPlRoZXJl J3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWtpdHRlbi1hZXMtY3RzLWhtYWMtc2hhMi0wNw0KPg0K PkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj5odHRw czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1raXR0ZW4tYWVzLWN0cy1o bWFjLXNoYTItMDcNCj4NCj4NCj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+dW50aWwgdGhlIGh0bWxp emVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4N Cj5JbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6 DQo+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4NCj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPktpdHRlbiBtYWlsaW5nIGxpc3QN Cj5LaXR0ZW5AaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2tpdHRlbg0K From nobody Thu Dec 3 19:05:09 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6FF1B2AB9 for ; Thu, 3 Dec 2015 19:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_STOP=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhroBmZkv-tj for ; Thu, 3 Dec 2015 19:05:07 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EBC01B2AB7 for ; Thu, 3 Dec 2015 19:05:07 -0800 (PST) X-AuditID: 12074424-f79216d00000156e-64-566102e13f0b Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 73.89.05486.1E201665; Thu, 3 Dec 2015 22:05:05 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id tB4355gM031542 for ; Thu, 3 Dec 2015 22:05:05 -0500 Received: from [18.101.8.224] (vpn-18-101-8-224.mit.edu [18.101.8.224]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tB4352qN009324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 3 Dec 2015 22:05:04 -0500 To: kitten@ietf.org References: <20151203182416.14249.59890.idtracker@ietfa.amsl.com> <8BBA724D-905D-4B7D-BE87-A8748D8A8F3E@mitre.org> From: Greg Hudson X-Enigmail-Draft-Status: N1110 Message-ID: <566102DE.5020708@mit.edu> Date: Thu, 3 Dec 2015 22:05:02 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <8BBA724D-905D-4B7D-BE87-A8748D8A8F3E@mitre.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrfuQKTHM4NszG4ujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEro+XyRaaCx3wVD9Z2MDUw/uLuYuTkkBAwkZjV1ssGYYtJXLi3 Hsjm4hASWMwksaHtIiOEc4xR4khfIytIlZDATSaJa08Nuhg5OIQFfCSuvvEGCYsICEvs3vqO GaKkROLCwQ1g5WwCyhLr929lgVggJ9HbPQnM5hVQk/j4qgfMZhFQkTh86C8TyEhRgQiJRTsy IUoEJU7OfAJWwilgKzH31y8wm1lAXeLPvEvMELa8RPPW2cwTGAVnIWmZhaRsFpKyBYzMqxhl U3KrdHMTM3OKU5N1i5MT8/JSi3TN9XIzS/RSU0o3MYICld1FZQdj8yGlQ4wCHIxKPLwMmxLC hFgTy4orcw8xSnIwKYnyPnwBFOJLyk+pzEgszogvKs1JLT7EKMHBrCTCq/QNKMebklhZlVqU D5OS5mBREued+8U3TEggPbEkNTs1tSC1CCYrw8GhJMGbz5gYJiRYlJqeWpGWmVOCkGbi4AQZ zgM03Amkhre4IDG3ODMdIn+KUVFKnHclSEIAJJFRmgfXC04kqRwPXjGKA70izNsFUsUDTEJw 3a+ABjMBDQ76GA8yuCQRISXVwKjzzma617OCec9F8yXLV2x+/mj/qndBXBYX/OS+VrRcMXKe Uyrz+1fHtJOcV6zsSr9WcE635WG4U3nk76KAZv1POuHiXHWOcwQXbuP8kmBu/68mS4/J/NjN r2nn/q59Z+j5oXfF1weKRy/Z/FPMX2F20bFog/AP20bp/Iao76sOeH/lmvj0zSQlluKMREMt 5qLiRADLZpyq/wIAAA== Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-07.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 03:05:09 -0000 On 12/03/2015 01:32 PM, Peck, Michael A wrote: > We would appreciate working group feedback on this new finally posted draft. This revision removes a random-to-key() invocation in section 4, which defines the PBKDF2 construction for deriving long-term keys from passphrases. I don't think that's right. (If I seem to be reversing myself, note that the action item was to remove random-to-key() from section 3, and that part is fine.) Abstractly, random-to-key() maps a byte string of exactly 128 or 256 bits to a protocol key using the identity function. KDF-HMAC-SHA2() outputs a byte string after the change to section 3. Since PBKDF2() outputs a byte string, we must convert it to a protocol key with random-to-key() to have the right abstract type as input to KDF-HMAC-SHA2(). Moreover, , we must apply random-to-key() again to convert the output of KDF-HMAC-SHA2() to a protocol key. So, I think we want to preserve the random-to-key() for the assignment to tkey, and add another one for the assignment to base-key. None of this is likely to affect implementation correctness, of course, since random-to-key() is the identity function. > While removing truncation from the PRF output, we also changed (with the goal of simplifying) the PRF computation (end of section 5 / top of page 7). I think that's a good change. The old definition performed two HMACs, the first with a fixed string and the second with the PRF input. The new definition stuffs the PRF input into the first HMAC along with the fixed parts. There's some trailing whitespace at the end of some lines in the text; you may want to check for that. I was able to verify all of the test vectors using my Python implementation. (I didn't check the intermediate values.) It's in the the aes-sha2 branch of https://github.com/greghudson/pyk5 ; no promises of stability. From nobody Thu Dec 3 19:07:59 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF57D1B2AC9 for ; Thu, 3 Dec 2015 19:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.388 X-Spam-Level: X-Spam-Status: No, score=0.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_STOP=2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ap3OS0q-cjf0 for ; Thu, 3 Dec 2015 19:07:57 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CE641B2ABA for ; Thu, 3 Dec 2015 19:07:57 -0800 (PST) Received: by us.padl.com with ESMTP id tB437j9S022522; Thu, 3 Dec 2015 22:07:52 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luke Howard In-Reply-To: <8BBA724D-905D-4B7D-BE87-A8748D8A8F3E@mitre.org> Date: Fri, 4 Dec 2015 14:07:37 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151203182416.14249.59890.idtracker@ietfa.amsl.com> <8BBA724D-905D-4B7D-BE87-A8748D8A8F3E@mitre.org> To: "Peck, Michael A" X-Mailer: Apple Mail (2.3096.5) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.4 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-07.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 03:07:59 -0000 Hi Mike, Thanks for this. I=E2=80=99ve updated the Heimdal implementation with = the PRF changes and verified all of the test vectors. https://github.com/heimdal/heimdal/tree/lukeh/aes-cts-hmac-sha2 Cheers, Luke > On 4 Dec 2015, at 5:32 AM, Peck, Michael A wrote: >=20 > Hi - >=20 > We would appreciate working group feedback on this new finally posted = draft. > I believe we=E2=80=99ve addressed all of the action items from Ben=E2=80= =99s April 17 email (quoted below). >=20 > While removing truncation from the PRF output, we also changed (with = the goal of simplifying) the PRF computation (end of section 5 / top of = page 7). > If the new computation isn=E2=80=99t desired, please let us know and = we can change it back. >=20 > We re-did the encryption and checksum test vectors to use the Kc, Ke, = and Ki values generated by the key derivation test vectors so that all = the steps would be shown. > We also added verbosity to the PRF test vectors. >=20 > Thanks, > Mike >=20 >=20 > On 4/17/2015 5:23 PM, Benjamin Kaduk wrote: >> That seems to leave us with the following action items: >> For the document editor: >> * remove truncation from the PRF output and use the natural hash = output >> length >> * remove the use of random-to-key() and discussion of constant values = from >> section 3 >> * add an output length argument to KDF-HMAC-SHA2() and adjust text >> accordingly >> * update test vectors to include base keys and key usage values for = all >> test cases >> * reword the text discussing aes256 with 192-bit keys >=20 >=20 >=20 >=20 >=20 > On 12/3/15, 1:24 PM, "Kitten on behalf of internet-drafts@ietf.org" = wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Common Authentication Technology = Next Generation Working Group of the IETF. >>=20 >> Title : AES Encryption with HMAC-SHA2 for Kerberos 5 >> Authors : Michael J. Jenkins >> Michael A. Peck >> Kelley W. Burgin >> Filename : draft-ietf-kitten-aes-cts-hmac-sha2-07.txt >> Pages : 16 >> Date : 2015-12-03 >>=20 >> Abstract: >> This document specifies two encryption types and two corresponding >> checksum types for Kerberos 5. The new types use AES in CTS mode >> (CBC mode with ciphertext stealing) for confidentiality and HMAC = with >> a SHA-2 hash for integrity. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-07 >>=20 >> A diff from the previous version is available at: >> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-aes-cts-hmac-sha2-07= >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> Kitten mailing list >> Kitten@ietf.org >> https://www.ietf.org/mailman/listinfo/kitten > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten -- www.lukehoward.com soundcloud.com/lukehoward From nobody Fri Dec 4 09:22:24 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B6F1A8AEF for ; Fri, 4 Dec 2015 09:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWoic1nVKv5n for ; Fri, 4 Dec 2015 09:22:22 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A96C1A8AE9 for ; Fri, 4 Dec 2015 09:22:21 -0800 (PST) X-AuditID: 1209190e-f79046d0000036c0-ac-5661cbcc2d7c Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id B0.32.14016.CCBC1665; Fri, 4 Dec 2015 12:22:20 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id tB4HMJKX024404 for ; Fri, 4 Dec 2015 12:22:20 -0500 Received: from [18.101.8.91] (vpn-18-101-8-91.mit.edu [18.101.8.91]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tB4HMHRg019332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 4 Dec 2015 12:22:19 -0500 To: kitten@ietf.org References: <20151203182416.14249.59890.idtracker@ietfa.amsl.com> <8BBA724D-905D-4B7D-BE87-A8748D8A8F3E@mitre.org> From: Greg Hudson X-Enigmail-Draft-Status: N1110 Message-ID: <5661CBC9.7010404@mit.edu> Date: Fri, 4 Dec 2015 12:22:17 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <8BBA724D-905D-4B7D-BE87-A8748D8A8F3E@mitre.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixG6nonvmdGKYwdz16hZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpLW2IIdvBXzGiezNjCe5Opi5OSQEDCRmLf5GSOELSZx4d56 ti5GLg4hgcVMEkeXvWKBcI4xSpy/eokVwrnGJDGv4w9TFyMHh7CAj8TVN94g3SICwhK7t75j BrGFBEokLhzcwApiswkoS6zfv5UFYoOcRG/3JDCbV0BNYs6aX6wgY1gEVCT2nA8BMUUFIiQW 7ciEqBCUODnzCVg1p4CtxNxfv8BsZgF1iT/zLjFD2PISzVtnM09gFJyFpGUWkrJZSMoWMDKv YpRNya3SzU3MzClOTdYtTk7My0st0jXWy80s0UtNKd3ECApTTkm+HYxfDyodYhTgYFTi4V2x PiFMiDWxrLgy9xCjJAeTkijvrWOJYUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeJllgHK8KYmV ValF+TApaQ4WJXHeuV98w4QE0hNLUrNTUwtSi2CyMhwcShK8z04BNQoWpaanVqRl5pQgpJk4 OEGG8wANfwdSw1tckJhbnJkOkT/FqCglzvsIJCEAksgozYPrBaeRVI7oV4ziQK8I8zqDVPEA UxBc9yugwUxAg4M+xoMMLklESEk1MOq5zN0rUFI3SbG409ZFoSPQ8HKkpFWm66rXTG5RgZ5X g80MfzSwrlmjOmX/B9X6GF4nYfPF5Tw9rP5rxadFWCy51aMRtjSPOcuJLU818rhJgOAlliuZ fVeWXw/lZqwwEjjHe/+g6vSZx/KexahPnyH7htOi0VLAStSB9X9KMgtjlMwlQ00lluKMREMt 5qLiRAC7QjYF/gIAAA== Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-07.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 17:22:24 -0000 On 12/03/2015 01:32 PM, Peck, Michael A wrote: > We would appreciate working group feedback on this new finally posted draft. I'm looking at the description of ciphertext state in this draft versus the description in RFC 3962. RFC 3962 says: The initial vector carried out from one encryption for use in a subsequent encryption is the next-to-last block of the encryption output; this is the encrypted form of the last plaintext block. When decrypting, the next-to-last block of the supplied ciphertext is carried forward as the next initial vector. If only one ciphertext block is available (decrypting one block, or encrypting one block or less), then that one block is carried out instead. The draft says: ciphertext = C | H[1..h] cipherstate = the last full (128 bit) block of C (i.e. the next-to-last block if the last block is not a full 128 bits) I believe the intent was to align the draft with RFC 3962 (in that a previous version of the draft used a simpler construction involving the confounder, and it was later changed), but these definitions are not identical when the last plaintext block is a full 128 bits, unless I'm missing something. As an implementor, I would like to reuse the AES enc-provider in MIT krb5, which consumes and outputs ciphertext state, so I would prefer that the definitions align. It looks like Luke's implementation for Heimdal also reuses the _krb5_evp_encrypt_cts() function, which consumes and outputs ciphertext state. (This discussion does not affect the test vectors, which do not use cipher state. Cipher state is really only used for the obsolete krb5 rlogin, as far as I know.) From nobody Fri Dec 4 14:53:00 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0321ACD92 for ; Fri, 4 Dec 2015 14:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_xsbQmLherr for ; Fri, 4 Dec 2015 14:52:58 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0135D1ACD83 for ; Fri, 4 Dec 2015 14:52:57 -0800 (PST) Received: by us.padl.com with ESMTP id tB4MqpIY015686; Fri, 4 Dec 2015 17:52:54 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luke Howard In-Reply-To: <5661CBC9.7010404@mit.edu> Date: Sat, 5 Dec 2015 09:52:49 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151203182416.14249.59890.idtracker@ietfa.amsl.com> <8BBA724D-905D-4B7D-BE87-A8748D8A8F3E@mitre.org> <5661CBC9.7010404@mit.edu> To: Greg Hudson X-Mailer: Apple Mail (2.3096.5) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.8 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-07.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 22:52:59 -0000 Thanks for pointing this out Greg =E2=80=93 obviously, yes, another vote = for RFC3962 alignment from me (also prefer to reuse code). =E2=80=94 Luke > On 5 Dec 2015, at 4:22 AM, Greg Hudson wrote: >=20 > On 12/03/2015 01:32 PM, Peck, Michael A wrote: >> We would appreciate working group feedback on this new finally posted = draft. >=20 > I'm looking at the description of ciphertext state in this draft = versus > the description in RFC 3962. RFC 3962 says: >=20 > The initial vector carried out from one encryption for use in a > subsequent encryption is the next-to-last block of the encryption > output; this is the encrypted form of the last plaintext block. = When > decrypting, the next-to-last block of the supplied ciphertext is > carried forward as the next initial vector. If only one ciphertext > block is available (decrypting one block, or encrypting one block or > less), then that one block is carried out instead. >=20 > The draft says: >=20 > ciphertext =3D C | H[1..h] > cipherstate =3D the last full (128 bit) block of C > (i.e. the next-to-last block if the last block > is not a full 128 bits) >=20 > I believe the intent was to align the draft with RFC 3962 (in that a > previous version of the draft used a simpler construction involving = the > confounder, and it was later changed), but these definitions are not > identical when the last plaintext block is a full 128 bits, unless I'm > missing something. >=20 > As an implementor, I would like to reuse the AES enc-provider in MIT > krb5, which consumes and outputs ciphertext state, so I would prefer > that the definitions align. It looks like Luke's implementation for > Heimdal also reuses the _krb5_evp_encrypt_cts() function, which = consumes > and outputs ciphertext state. >=20 > (This discussion does not affect the test vectors, which do not use > cipher state. Cipher state is really only used for the obsolete krb5 > rlogin, as far as I know.) >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten -- www.lukehoward.com soundcloud.com/lukehoward From nobody Mon Dec 7 00:53:08 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84AA71B3552 for ; Mon, 7 Dec 2015 00:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMZtZNxWXmOL for ; Mon, 7 Dec 2015 00:53:04 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80E691B3550 for ; Mon, 7 Dec 2015 00:53:04 -0800 (PST) Received: by us.padl.com with ESMTP id tB78qkpD029803; Mon, 7 Dec 2015 03:52:54 -0500 From: Luke Howard Content-Type: multipart/alternative; boundary="Apple-Mail=_5A9F2740-CBB9-447A-8AE4-58C97A54ACDE" Date: Mon, 7 Dec 2015 19:52:35 +1100 To: "kitten@ietf.org" Message-Id: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,HTML_MESSAGE,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Archived-At: Subject: [kitten] AES-GCM for Kerberos GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 08:53:06 -0000 --Apple-Mail=_5A9F2740-CBB9-447A-8AE4-58C97A54ACDE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I had a bit of a play with adding support for AES-GCM to Heimdal. Notes: * GCM is added as a RFC 3961 enctype, but it=E2=80=99s really a = pseudo-enctype =E2=80=93 were it to be documented, it might not be at = the 3961 layer at all (except camping on the enctype namespace for = negotiation). * The target application is only GSS, and it=E2=80=99s assumed it'd be = negotiated using RFC4537. * Encryption/decryption functions are extended to support associated = data (this was already there in the implementation, but 3961 would need = to be updated). * KDF is SP800-108 in counter/feedback mode with CMAC, this is used both = for key derivation and for RFC4401 PRF. (Wasn=E2=80=99t sure if was safe = to use GMAC here?) Ke =3D KDF-CMAC(base-key, usage | 0xAA) PRF =3D KDF-CMAC(base-key, "prf" | octet-string) There is no Ki/Kc because there is no separate checksum or integrity = usage. * No string-to-key function is defined. * No checksum types are defined, instead MIC tokens are constructed = using the encryption function with an empty plaintext. I figured this = was less intrusive than extending the checksum function to take a cipher = state parameter, but comments are welcome. * The cipher state is the GCM initialisation vector length; the length = is 96 bits (excluding counter). A (key, IV) combination must never be = reused. TOK_ID || Flags || 0xFF || SND_SEQ is used as the initialisation = vector for all RFC 4121 tokens. * The encrypted copy of the 4121 token header is removed (it is = protected by the IV, except for the EC field which implementations must = validate independently). We could additionally protect it as associated = data. Implementation (forked off aes-sha2 work): https://github.com/heimdal/heimdal/tree/lukeh/aes-gcm = =E2=80=94 Luke= --Apple-Mail=_5A9F2740-CBB9-447A-8AE4-58C97A54ACDE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I had a bit of a play with = adding support for AES-GCM to Heimdal. Notes:

* GCM is added as a RFC = 3961 enctype, but it=E2=80=99s really a pseudo-enctype =E2=80=93 were it = to be documented, it might not be at the 3961 layer at all (except = camping on the enctype namespace for negotiation).

* The target application = is only GSS, and it=E2=80=99s assumed it'd be negotiated using = RFC4537.

* = Encryption/decryption functions are extended to support associated data = (this was already there in the implementation, but 3961 would need to be = updated).

* = KDF is SP800-108 in counter/feedback mode with CMAC, this is used both = for key derivation and for RFC4401 PRF. (Wasn=E2=80=99t sure if was safe = to use GMAC here?)

   Ke  =3D KDF-CMAC(base-key, usage | 0xAA)
   PRF =3D KDF-CMAC(base-key, "prf" | =
octet-string)

There is no Ki/Kc because there is no separate checksum or = integrity usage.

* No string-to-key function is defined.

* No checksum types are = defined, instead MIC tokens are constructed using the encryption = function with an empty plaintext. I figured this was less intrusive than = extending the checksum function to take a cipher state parameter, but = comments are welcome.

* The cipher state is the GCM initialisation vector length; = the length is 96 bits (excluding counter). A (key, IV) combination must = never be reused. TOK_ID || Flags || 0xFF || SND_SEQ is used as the = initialisation vector for all RFC 4121 tokens.

* The encrypted copy of the 4121 token = header is removed (it is protected by the IV, except for the EC field = which implementations must validate independently). We could = additionally protect it as associated data.

Implementation (forked = off aes-sha2 work):

https://github.com/heimdal/heimdal/tree/lukeh/aes-gcm
=

=E2=80=94 = Luke
= --Apple-Mail=_5A9F2740-CBB9-447A-8AE4-58C97A54ACDE-- From nobody Mon Dec 7 01:27:22 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05411B35E9 for ; Mon, 7 Dec 2015 01:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMRqvJ-7oK2H for ; Mon, 7 Dec 2015 01:27:19 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFE0F1B35E7 for ; Mon, 7 Dec 2015 01:27:19 -0800 (PST) Received: by us.padl.com with ESMTP id tB79R7Ug030323; Mon, 7 Dec 2015 04:27:12 -0500 From: Luke Howard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: <1545C044-A479-4976-B4C1-D1E4CCBE3707@padl.com> Date: Mon, 7 Dec 2015 20:27:04 +1100 References: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> In-Reply-To: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> To: "kitten@ietf.org" X-Mailer: iPhone Mail (13B143) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: BAYES_00,MIME_QP_LONG_LINE,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.2 Archived-At: Subject: Re: [kitten] AES-GCM for Kerberos GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 09:27:20 -0000 > * The cipher state is the GCM initialisation vector length; the length is 9= 6 bits (excluding counter). A (key, IV) combination must never be reused. TO= K_ID || Flags || 0xFF || SND_SEQ is used as the initialisation vector for al= l RFC 4121 tokens. Poorly worded - the cipher state is the GCM IV, the GCM IV is 96 bits long.= From nobody Mon Dec 7 04:44:46 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362881ACE3D for ; Mon, 7 Dec 2015 04:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAVzN7BFZIj3 for ; Mon, 7 Dec 2015 04:44:44 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 022E01ACDC2 for ; Mon, 7 Dec 2015 04:44:43 -0800 (PST) Received: by us.padl.com with ESMTP id tB7CiYiR004074; Mon, 7 Dec 2015 07:44:39 -0500 From: Luke Howard Content-Type: multipart/alternative; boundary="Apple-Mail=_FDBA0852-7962-4684-A008-BE903CD6022F" Message-Id: <0C4E6021-4054-46BF-B2C0-DF179CB6DFF8@padl.com> Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Date: Mon, 7 Dec 2015 23:44:33 +1100 References: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> To: "kitten@ietf.org" In-Reply-To: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> X-Mailer: Apple Mail (2.3096.5) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,HTML_MESSAGE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.8 Archived-At: Subject: Re: [kitten] AES-GCM for Kerberos GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 12:44:45 -0000 --Apple-Mail=_FDBA0852-7962-4684-A008-BE903CD6022F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 7 Dec 2015, at 7:52 PM, Luke Howard wrote: >=20 > * KDF is SP800-108 in counter/feedback mode with CMAC, this is used = both for key derivation and for RFC4401 PRF. (Wasn=E2=80=99t sure if was = safe to use GMAC here?) >=20 > Ke =3D KDF-CMAC(base-key, usage | 0xAA) > PRF =3D KDF-CMAC(base-key, "prf" | octet-string) I can=E2=80=99t find much about using a GMAC-based KDF, and I have no = idea how safe it is in this usage with a constant IV. Still, if it=E2=80=99= s possible, it would certainly be nice and symmetrical. =E2=80=94 Luke= --Apple-Mail=_FDBA0852-7962-4684-A008-BE903CD6022F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 7 Dec 2015, at 7:52 PM, Luke Howard <lukeh@padl.com> = wrote:

* KDF is SP800-108 in = counter/feedback mode with CMAC, this is used both for key derivation = and for RFC4401 PRF. (Wasn=E2=80=99t sure if was safe to use GMAC = here?)

   Ke  =3D =
KDF-CMAC(base-key, usage | 0xAA)
   =
PRF =3D KDF-CMAC(base-key, "prf" | =
octet-string)

I can=E2=80=99t find much about using a = GMAC-based KDF, and I have no idea how safe it is in this usage with a = constant IV. Still, if it=E2=80=99s possible, it would certainly be nice = and symmetrical.

=E2=80=94 = Luke
= --Apple-Mail=_FDBA0852-7962-4684-A008-BE903CD6022F-- From nobody Mon Dec 7 14:03:23 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367B01B29C2 for ; Mon, 7 Dec 2015 14:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ww6eZQUwLQlm for ; Mon, 7 Dec 2015 14:03:20 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F0821B29CB for ; Mon, 7 Dec 2015 14:03:20 -0800 (PST) Received: by us.padl.com with ESMTP id tB7M35v2026439; Mon, 7 Dec 2015 17:03:10 -0500 From: Luke Howard Content-Type: multipart/alternative; boundary="Apple-Mail=_804A0843-B992-42AE-AB81-F622A4A05DE8" Message-Id: <5587DA83-6CC9-4AE3-928D-F18074DA2511@padl.com> Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Date: Tue, 8 Dec 2015 09:03:03 +1100 References: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> <0C4E6021-4054-46BF-B2C0-DF179CB6DFF8@padl.com> To: "kitten@ietf.org" In-Reply-To: <0C4E6021-4054-46BF-B2C0-DF179CB6DFF8@padl.com> X-Mailer: Apple Mail (2.3096.5) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,HTML_MESSAGE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.8 Archived-At: Subject: Re: [kitten] AES-GCM for Kerberos GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 22:03:23 -0000 --Apple-Mail=_804A0843-B992-42AE-AB81-F622A4A05DE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 7 Dec 2015, at 11:44 PM, Luke Howard wrote: >=20 >=20 >> On 7 Dec 2015, at 7:52 PM, Luke Howard > wrote: >>=20 >> * KDF is SP800-108 in counter/feedback mode with CMAC, this is used = both for key derivation and for RFC4401 PRF. (Wasn=E2=80=99t sure if was = safe to use GMAC here?) >>=20 >> Ke =3D KDF-CMAC(base-key, usage | 0xAA) >> PRF =3D KDF-CMAC(base-key, "prf" | octet-string) >=20 >=20 > I can=E2=80=99t find much about using a GMAC-based KDF, and I have no = idea how safe it is in this usage with a constant IV. Still, if it=E2=80=99= s possible, it would certainly be nice and symmetrical. I did find this however: http://marc.info/?l=3Dcfrg&m=3D143336328026648&w=3D2 = https://www.ietf.org/mail-archive/web/cfrg/current/msg02689.html = =E2=80=94 Luke= --Apple-Mail=_804A0843-B992-42AE-AB81-F622A4A05DE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 7 Dec 2015, at 11:44 PM, Luke Howard <lukeh@padl.com> = wrote:


On 7 Dec 2015, at 7:52 PM, Luke Howard <lukeh@padl.com> = wrote:

* KDF is SP800-108 in = counter/feedback mode with CMAC, this is used both for key derivation = and for RFC4401 PRF. (Wasn=E2=80=99t sure if was safe to use GMAC = here?)

   Ke  =3D =
KDF-CMAC(base-key, usage | 0xAA)
   =
PRF =3D KDF-CMAC(base-key, "prf" | =
octet-string)

I can=E2=80=99t find much about using a = GMAC-based KDF, and I have no idea how safe it is in this usage with a = constant IV. Still, if it=E2=80=99s possible, it would certainly be nice = and symmetrical.

I did = find this however:


=E2=80=94 = Luke
= --Apple-Mail=_804A0843-B992-42AE-AB81-F622A4A05DE8-- From nobody Mon Dec 7 14:08:19 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4BB1B29D3 for ; Mon, 7 Dec 2015 14:08:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-6t87R00Omw for ; Mon, 7 Dec 2015 14:08:16 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 096101B29D0 for ; Mon, 7 Dec 2015 14:08:15 -0800 (PST) X-AuditID: 12074425-f793c6d000006975-16-5666034ec4e9 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 71.DD.26997.E4306665; Mon, 7 Dec 2015 17:08:14 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id tB7M8D3K012932; Mon, 7 Dec 2015 17:08:14 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tB7M8BUh003104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Dec 2015 17:08:13 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id tB7M8AAM009901; Mon, 7 Dec 2015 17:08:10 -0500 (EST) Date: Mon, 7 Dec 2015 17:08:10 -0500 (EST) From: Benjamin Kaduk To: Luke Howard In-Reply-To: <5587DA83-6CC9-4AE3-928D-F18074DA2511@padl.com> Message-ID: References: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> <0C4E6021-4054-46BF-B2C0-DF179CB6DFF8@padl.com> <5587DA83-6CC9-4AE3-928D-F18074DA2511@padl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; boundary="-559023410-92256146-1449526014=:26829" Content-ID: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGKsWRmVeSWpSXmKPExsUixCmqrOvHnBZm8PWKjsXRzatYLO5e+s/u wOSxZMlPJo+5H6axBDBFcdmkpOZklqUW6dslcGXMfLeTreACf8XWpsnMDYwveboYOTkkBEwk Hj7oZIKwxSQu3FvP1sXIxSEksJhJoq3vCROEs4FR4t/V5YwQzkEmiYmfpzKCtAgJ1Eu0TzvN AmKzCGhJ/F6znR3EZhNQkZj5ZiMbiC0ioCAxef9aZhCbWUBd4tuZN0C9HBzCAkYSl9rjQcKc AjYSR/ueMYGEeQUcJU7eNYZYNZtR4k/DB7AxogI6Eqv3TwFbxSsgKHFy5hMWiJH+Etd6mlhA epmBer98KJ3AKDQLSdUsJFWzEKogwjoSN2csZoOwtSXu32yDsh0lVu19wraAkW0Vo2xKbpVu bmJmTnFqsm5xcmJeXmqRroVebmaJXmpK6SZGUHSwu6juYJxwSOkQowAHoxIPr8LJ1DAh1sSy 4srcQ4ySHExKoryy34FCfEn5KZUZicUZ8UWlOanFhxglOJiVRHjPPwDK8aYkVlalFuXDpKQ5 WJTEeed+8Q0TEkhPLEnNTk0tSC2CycpwcChJ8AoypYUJCRalpqdWpGXmlCCkmTg4QYbzAA3P ZgSq4S0uSMwtzkyHyJ9iVJQS5z0JkhAASWSU5sH1gpPXbibVV4ziQK8I80qArOABJj647ldA g5mABke9TAYZXJKIkJJqYOwtnC33ZlpSTvaGtfpL0v/YGlXp5+xw2MgYGpjm6dEjWxd/9UVv U/zOq7JHl6fvD/gTterezwOJvw4eU/YUuT1Z4bRdu/pXm2C5pk+b3nl9PXlL4F77xdcq7xR+ 8PMY3ZrXxCzkuEvOzNjvwex3MT9qqyLfbzxRq/Mox+DolA9rJmS6nL4z9bYSS3FGoqEWc1Fx IgDW5RGsOQMAAA== Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] AES-GCM for Kerberos GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 22:08:18 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-92256146-1449526014=:26829 Content-Type: TEXT/PLAIN; charset=ISO-8859-7 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: On Mon, 7 Dec 2015, Luke Howard wrote: > > > On 7 Dec 2015, at 11:44 PM, Luke Howard wrote: > > > > > >> On 7 Dec 2015, at 7:52 PM, Luke Howard > wrote: > >> > >> * KDF is SP800-108 in counter/feedback mode with CMAC, this is used bo= th for key derivation and for RFC4401 PRF. (Wasn=A2t sure if was safe to us= e GMAC here?) > >> > >> Ke =3D KDF-CMAC(base-key, usage | 0xAA) > >> PRF =3D KDF-CMAC(base-key, "prf" | octet-string) > > > > > > I can=A2t find much about using a GMAC-based KDF, and I have no idea ho= w safe it is in this usage with a constant IV. Still, if it=A2s possible, i= t would certainly be nice and symmetrical. > > I did find this however: > > http://marc.info/?l=3Dcfrg&m=3D143336328026648&w=3D2 > https://www.ietf.org/mail-archive/web/cfrg/current/msg02689.html Perhaps I am just remembering those posts, but I do agree that GMAC is not appropriate for KDF usage. > * No checksum types are defined, instead MIC tokens are constructed > using the encryption function with an empty plaintext. I figured this > was less intrusive than extending the checksum function to take a cipher > state parameter, but comments are > welcome. That seems reasonable at first glance. I did not get to take a glance at the code itself yet, but thanks for putting together the proof-of-concept. Do you have any performance numbers for comparison? -Ben ---559023410-92256146-1449526014=:26829-- From nobody Mon Dec 7 14:17:34 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB891B29D5 for ; Mon, 7 Dec 2015 14:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdaMwjiRfKjQ for ; Mon, 7 Dec 2015 14:17:32 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 230171B29E1 for ; Mon, 7 Dec 2015 14:17:32 -0800 (PST) Received: by us.padl.com with ESMTP id tB7MGObA027753; Mon, 7 Dec 2015 17:17:29 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luke Howard In-Reply-To: Date: Tue, 8 Dec 2015 09:17:27 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> <0C4E6021-4054-46BF-B2C0-DF179CB6DFF8@padl.com> <5587DA83-6CC9-4AE3-928D-F18074DA2511@padl.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3096.5) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.8 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] AES-GCM for Kerberos GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 22:17:33 -0000 > On 8 Dec 2015, at 9:08 AM, Benjamin Kaduk wrote: >=20 > I did not get to take a glance at the code itself yet, but thanks for > putting together the proof-of-concept. Do you have any performance > numbers for comparison? Not yet but given this is the principal motivation for GCM, I should = really get some together. Will do. =E2=80=94 Luke From nobody Mon Dec 7 16:28:56 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29CF1A895E for ; Mon, 7 Dec 2015 16:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3CIfGRN348N for ; Mon, 7 Dec 2015 16:28:54 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A00F71A895D for ; Mon, 7 Dec 2015 16:28:54 -0800 (PST) Received: by us.padl.com with ESMTP id tB80SmlK032200; Mon, 7 Dec 2015 19:28:52 -0500 From: Luke Howard Content-Type: multipart/alternative; boundary="Apple-Mail=_BC76E5E3-7D40-4E92-B2D3-0BAE71794E04" Message-Id: <1D0FEA3E-A8D7-4702-B228-FAF697BB427A@padl.com> Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Date: Tue, 8 Dec 2015 11:28:47 +1100 References: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> To: "kitten@ietf.org" In-Reply-To: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> X-Mailer: Apple Mail (2.3096.5) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED, AWL, BAYES_00, HTML_MESSAGE, MIME_QP_LONG_LINE, USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.7 Archived-At: Subject: Re: [kitten] AES-GCM for Kerberos GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 00:28:55 -0000 --Apple-Mail=_BC76E5E3-7D40-4E92-B2D3-0BAE71794E04 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 7 Dec 2015, at 7:52 PM, Luke Howard wrote: >=20 > * The cipher state is the GCM initialisation vector length; the length = is 96 bits (excluding counter). A (key, IV) combination must never be = reused. TOK_ID || Flags || 0xFF || SND_SEQ is used as the initialisation = vector for all RFC 4121 tokens. FWIW I took a quick look at IPsec (RFC4106 s8.1) and we could use that = approach for IV construction =E2=80=93 make the key length 20 (or 36) = bytes and construct the IV as: last four bytes Ke || SND_SEQ however this lacks a direction bit, so we=E2=80=99d most likely need to = steal the high bit from SND_SEQ which halves the number of messages that = can be transmitted (perhaps not a practical issue). Nico doesn=E2=80=99t think this is worth worrying about (GCM spec says = that it=E2=80=99s OK to have a completely deterministic IV as long as = it=E2=80=99s not reused with the same key), but perhaps the extra = entropy / consistency with TLS/IPsec is a good idea? =E2=80=94 Luke= --Apple-Mail=_BC76E5E3-7D40-4E92-B2D3-0BAE71794E04 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 7 Dec 2015, at 7:52 PM, Luke Howard <lukeh@padl.com> = wrote:

* The cipher state is the GCM = initialisation vector length; the length is 96 bits (excluding counter). = A (key, IV) combination must never be reused. TOK_ID || Flags || 0xFF || = SND_SEQ is used as the initialisation vector for all RFC 4121 = tokens.

FWIW I took a = quick look at IPsec (RFC4106 s8.1) and we could use that approach for IV = construction =E2=80=93 make the key length 20 (or 36) bytes and = construct the IV as:

last four bytes = Ke || SND_SEQ

however this lacks a = direction bit, so we=E2=80=99d most likely need to steal the high bit = from SND_SEQ which halves the number of messages that can be transmitted = (perhaps not a practical issue).

Nico = doesn=E2=80=99t think this is worth worrying about (GCM spec says that = it=E2=80=99s OK to have a completely deterministic IV as long as it=E2=80=99= s not reused with the same key), but perhaps the extra entropy / = consistency with TLS/IPsec is a good idea?

=E2=80=94 Luke
= --Apple-Mail=_BC76E5E3-7D40-4E92-B2D3-0BAE71794E04-- From nobody Mon Dec 7 20:06:18 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD151B2BF7 for ; Mon, 7 Dec 2015 20:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.582 X-Spam-Level: *** X-Spam-Status: No, score=3.582 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_MEEDS=5.494, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sL6kR7WBAaqS for ; Mon, 7 Dec 2015 20:06:15 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8241E1B2BF2 for ; Mon, 7 Dec 2015 20:06:15 -0800 (PST) Received: by us.padl.com with ESMTP id tB8467nt007759; Mon, 7 Dec 2015 23:06:13 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luke Howard In-Reply-To: <1D0FEA3E-A8D7-4702-B228-FAF697BB427A@padl.com> Date: Tue, 8 Dec 2015 15:06:06 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <3C12FB9B-196C-4926-B13B-44F826F7EF4E@padl.com> References: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> <1D0FEA3E-A8D7-4702-B228-FAF697BB427A@padl.com> To: "kitten@ietf.org" X-Mailer: Apple Mail (2.3096.5) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.9 Archived-At: Subject: Re: [kitten] AES-GCM for Kerberos GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 04:06:16 -0000 OK, I changed the implementation to more closely reflect other IETF = usage of GCM. This gives the IV some more entropy I assume is not a bad = thing. The RFC3961 key length is now 20 bytes for aes128-gcm-128 and 36 bytes = for aes128-gcm-128; the last four bytes are used to salt the IV in the = same manner as TLS and IPsec. The initialisation vector exposed at the 3961 level is now only eight = bytes long and this meeds to include both a direction flag and the = sequence number. Hence only 2^63 messages can be sent before the = sequence number wraps (not a problem with Heimdal which only uses 32-bit = sequence numbers, but perhaps an issue with other implementations). The = first bit of the initialisation vector is set if the message is sent by = the acceptor, unset if not. Because the IV now only protects the sequence number, rather than most = of the token header, the entire token header is input as the last item = of associated data, for both Wrap and MIC tokens. (We could just include = the first 8 bytes but I see no reason not to protect the entire header.) =20 Thoughts welcome (I know Nico thinks this change was not necessary!). =E2=80=94 Luke= From nobody Mon Dec 7 21:01:10 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743061A1BD9 for ; Mon, 7 Dec 2015 21:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJnQhTPSp1BG for ; Mon, 7 Dec 2015 21:01:06 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C91E31A1B6B for ; Mon, 7 Dec 2015 21:01:04 -0800 (PST) X-AuditID: 12074425-f793c6d000006975-a8-5666640f8672 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id DD.5F.26997.F0466665; Tue, 8 Dec 2015 00:01:03 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id tB8512r5021596; Tue, 8 Dec 2015 00:01:02 -0500 Received: from [18.101.8.132] (vpn-18-101-8-132.mit.edu [18.101.8.132]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tB8510rV032510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 8 Dec 2015 00:01:01 -0500 To: Luke Howard , "kitten@ietf.org" References: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> <1D0FEA3E-A8D7-4702-B228-FAF697BB427A@padl.com> From: Greg Hudson Message-ID: <5666640C.2050401@mit.edu> Date: Tue, 8 Dec 2015 00:01:00 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <1D0FEA3E-A8D7-4702-B228-FAF697BB427A@padl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixG6nrsufkhZmsPucrMXRzatYLO5e+s/u wOSxZMlPJo+5H6axBDBFcdmkpOZklqUW6dslcGWse3ONueALU8XqS1OYGhiXMnUxcnJICJhI TNl4hhnCFpO4cG89WxcjF4eQwGImiQXvTrBDOBsYJe7OPgKVOcwksefsBsYuRg4OYQEjiUvt 8SDdIgKuErOXLWMDCQsJ5Er8nMELEmYTUJZYv38rC4jNK6AmMfn7RnYQm0VAReLKsz0sIOWi AhESi3ZkQpQISpyc+QSsnFPARqL1/iSw25gF9CR2XP/FCmHLSzRvnc08gVFgFpKWWUjKZiEp W8DIvIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXQi83s0QvNaV0EyM4SF1UdzBOOKR0iFGAg1GJ h1fhZGqYEGtiWXFl7iFGSQ4mJVHeVxZpYUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeFt1gXK8 KYmVValF+TApaQ4WJXHeuV98w4QE0hNLUrNTUwtSi2CyMhwcShK8HslAjYJFqempFWmZOSUI aSYOTpDhPEDDlUBqeIsLEnOLM9Mh8qcYdTkW/Li9lkmIJS8/L1VKnPdzElCRAEhRRmke3Bxw cknlaHnFKA70ljBvAMgoHmBigpv0CmgJE9CSqJfJIEtKEhFSUg2MYZwb7TOOmLzvVgn0uF35 aHL4veUp7RM+msSe0IhQSzgfvO2S77MJ/Wp7P/ruuXhBKrF48eKbe28ylifYi70KFz5hI5bw 1P5bX4qOVjaHUMy/R90urVY1ymG5jvfTpe87a5i5xyZM++z0K17j0UdmVpWz91f4Mqtv4l69 4/aZ8o1566Qei+krsRRnJBpqMRcVJwIADqKafQkDAAA= Archived-At: Subject: Re: [kitten] AES-GCM for Kerberos GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 05:01:07 -0000 On 12/07/2015 07:28 PM, Luke Howard wrote: > Nico doesn’t think this is worth worrying about (GCM spec says that it’s > OK to have a completely deterministic IV as long as it’s not reused with > the same key), but perhaps the extra entropy / consistency with > TLS/IPsec is a good idea? I agree with Nico; I think this is extra complexity we don't want or need. From nobody Mon Dec 7 21:47:39 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3428B1B2CC2 for ; Mon, 7 Dec 2015 21:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CasC8QDDIXnS for ; Mon, 7 Dec 2015 21:47:37 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36EB51B2CC1 for ; Mon, 7 Dec 2015 21:47:37 -0800 (PST) Received: by us.padl.com with ESMTP id tB85lMHH011422; Tue, 8 Dec 2015 00:47:26 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luke Howard In-Reply-To: <5666640C.2050401@mit.edu> Date: Tue, 8 Dec 2015 16:47:21 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> <1D0FEA3E-A8D7-4702-B228-FAF697BB427A@padl.com> <5666640C.2050401@mit.edu> To: Greg Hudson X-Mailer: Apple Mail (2.3096.5) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.9 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] AES-GCM for Kerberos GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 05:47:38 -0000 > On 8 Dec 2015, at 4:01 PM, Greg Hudson wrote: >=20 > On 12/07/2015 07:28 PM, Luke Howard wrote: >> Nico doesn=92t think this is worth worrying about (GCM spec says that = it=92s >> OK to have a completely deterministic IV as long as it=92s not reused = with >> the same key), but perhaps the extra entropy / consistency with >> TLS/IPsec is a good idea? >=20 > I agree with Nico; I think this is extra complexity we don't want or = need. OK. Are you OK with not protecting the token header in the MAC (i.e. = asserting valid values of EC and relying on the IV)? =97 Luke= From nobody Tue Dec 8 00:09:36 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF91F1A016E for ; Tue, 8 Dec 2015 00:09:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nj4ixROcJ6h2 for ; Tue, 8 Dec 2015 00:09:32 -0800 (PST) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83BA21A0167 for ; Tue, 8 Dec 2015 00:09:31 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 15B3B446FA; Tue, 8 Dec 2015 09:09:29 +0100 (CET) X-purgate-ID: 152705::1449562169-00001C04-5D2DC62E/0/0 X-purgate-size: 1256 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id CFB9C4013C; Tue, 8 Dec 2015 09:09:28 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 80B211A3A3; Tue, 8 Dec 2015 09:09:28 +0100 (CET) In-Reply-To: <5587DA83-6CC9-4AE3-928D-F18074DA2511@padl.com> To: Luke Howard Date: Tue, 8 Dec 2015 09:09:28 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20151208080928.80B211A3A3@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] AES-GCM for Kerberos GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 08:09:35 -0000 Luke Howard wrote: > >> Luke Howard wrote: >> >>> Luke Howard > wrote: >>> >>> * KDF is SP800-108 in counter/feedback mode with CMAC, this is used >>> both for key derivation and for RFC4401 PRF. (Wasn't sure if was >>> safe to use GMAC here?) >>> >>> Ke = KDF-CMAC(base-key, usage | 0xAA) >>> PRF = KDF-CMAC(base-key, "prf" | octet-string) >> >> >> I can't find much about using a GMAC-based KDF, and I have no idea >> how safe it is in this usage with a constant IV. Still, if it's >> possible, it would certainly be nice and symmetrical. > > I did find this however: > > http://marc.info/?l=cfrg&m=143336328026648&w=2 > https://www.ietf.org/mail-archive/web/cfrg/current/msg02689.html I assume that the hash function for use in the key derivation needs to have cryptographic hash properties. NIST SP 800-38D "Galois/Counter Mode (GCM) and GMAC", 2nd paragraph on page 10 of NIST SP 800-38D http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf GHASH is a keyed hash function but not, on its own, a cryptographic hash function. This Recommendation only approves GHASH for use within the context of GCM. -Martin From nobody Tue Dec 8 02:42:30 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C913D1ACDA1 for ; Tue, 8 Dec 2015 02:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMuIgNBYbjhC for ; Tue, 8 Dec 2015 02:42:27 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D5241ACD95 for ; Tue, 8 Dec 2015 02:42:26 -0800 (PST) Received: by us.padl.com with ESMTP id tB8AgH8k021632; Tue, 8 Dec 2015 05:42:20 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Luke Howard X-Mailer: iPhone Mail (13B143) In-Reply-To: <20151208080928.80B211A3A3@ld9781.wdf.sap.corp> Date: Tue, 8 Dec 2015 21:42:14 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <4B75DE7D-1DE8-4C35-8B96-C3500414E6A9@padl.com> References: <20151208080928.80B211A3A3@ld9781.wdf.sap.corp> To: "kitten@ietf.org" X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: BAYES_00,MIME_QP_LONG_LINE,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.2 Archived-At: Subject: Re: [kitten] AES-GCM for Kerberos GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 10:42:28 -0000 If we profile for GSS only, we could (ignoring=20 GSS PRF for a second) eliminate the need for key derivation entirely as ther= e is no Kc/Ki and the token ID in the IV disambiguates Wrap from MIC usage. But this might be risky if we are defining this at the 3961 level unless we c= an mandate the usage be part of the IV (but that means increasing the IV siz= e which affects performance and also changes some of the NIST guarantees abo= ut safety IIRC). Thoughts? Seems simplest to align with 3961 as closely as possible if defini= ng at this layer, else if defining at GSS layer we can be more creative. Sent from my iPhone > On 8 Dec 2015, at 19:09, Martin Rex wrote: >=20 > Luke Howard wrote: >>=20 >>> Luke Howard wrote: >>>=20 >>>> Luke Howard > wrote: >>>>=20 >>>> * KDF is SP800-108 in counter/feedback mode with CMAC, this is used >>>> both for key derivation and for RFC4401 PRF. (Wasn't sure if was >>>> safe to use GMAC here?) >>>>=20 >>>> Ke =3D KDF-CMAC(base-key, usage | 0xAA) >>>> PRF =3D KDF-CMAC(base-key, "prf" | octet-string) >>>=20 >>>=20 >>> I can't find much about using a GMAC-based KDF, and I have no idea >>> how safe it is in this usage with a constant IV. Still, if it's >>> possible, it would certainly be nice and symmetrical. >>=20 >> I did find this however: >>=20 >> http://marc.info/?l=3Dcfrg&m=3D143336328026648&w=3D2 >> https://www.ietf.org/mail-archive/web/cfrg/current/msg02689.html >=20 >=20 > I assume that the hash function for use in the key derivation > needs to have cryptographic hash properties. >=20 >=20 > NIST SP 800-38D "Galois/Counter Mode (GCM) and GMAC", > 2nd paragraph on page 10 of NIST SP 800-38D >=20 > http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf >=20 > GHASH is a keyed hash function but not, on its own, a cryptographic > hash function. This Recommendation only approves GHASH for use within > the context of GCM.=20 >=20 >=20 > -Martin From nobody Tue Dec 8 14:37:04 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494EB1ACCF0 for ; Tue, 8 Dec 2015 14:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.334 X-Spam-Level: X-Spam-Status: No, score=0.334 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qicw-rWtf_Ny for ; Tue, 8 Dec 2015 14:37:01 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9255B1ACCEB for ; Tue, 8 Dec 2015 14:37:01 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 3E6AD67409D; Tue, 8 Dec 2015 14:37:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=Yccyw9ueYFaFPMQ1yLSI8X9KwkA=; b=PjZvh0SmJ+E qY9xxb4+dwh479HUtZDrjLG+GqCdCKO4gaOvdgs3bkGsmJom9zOUqbZdNw6CXjKy 7h+uDIGRu/2p0xOKEWVLX0QtwCu8RGL1351myKGBwYfweG5jq+d+kFy7i5M6Ulh8 4SsnkZ/RSC39NWZbWhH/hza7rskDvUUU= Received: from localhost (108-207-244-100.lightspeed.austtx.sbcglobal.net [108.207.244.100]) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPA id 357A067406A; Tue, 8 Dec 2015 14:36:58 -0800 (PST) Date: Tue, 8 Dec 2015 16:36:57 -0600 From: Nico Williams To: Luke Howard Message-ID: <20151208223656.GD23318@localhost> References: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> <1D0FEA3E-A8D7-4702-B228-FAF697BB427A@padl.com> <5666640C.2050401@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] AES-GCM for Kerberos GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 22:37:03 -0000 On Tue, Dec 08, 2015 at 04:47:21PM +1100, Luke Howard wrote: > > On 8 Dec 2015, at 4:01 PM, Greg Hudson wrote: > > On 12/07/2015 07:28 PM, Luke Howard wrote: > >> Nico doesn=E2=80=99t think this is worth worrying about (GCM spec sa= ys that it=E2=80=99s > >> OK to have a completely deterministic IV as long as it=E2=80=99s not= reused with > >> the same key), but perhaps the extra entropy / consistency with > >> TLS/IPsec is a good idea? > >=20 > > I agree with Nico; I think this is extra complexity we don't want or = need. In particular: a deterministic IV construction is the key to preventing key/IV reuse, _and_, we only need entropy in the key. Entropy in the IV doesn't help security because whatever bits of it are randomly chosen have to be sent in the clear as otherwise the peer won't be able to reconstruct them. The IV cannot be secret for GSS because of the out of sequence token delivery/consumption requirement (well, it's an option, but one we want). For an RFC3961 octet stream application like AFS' rx the initial IV could be secret and non-deterministic, thereafter just a counter. In this case entropy in the IV might increase security, but we don't need that to make the enctype secure for GSS. Entropy in the IV doesn't help UNLESS you just cannot construct a deterministic IV. Since here we can, we should not have any entropy in the IV. > OK. Are you OK with not protecting the token header in the MAC (i.e. > asserting valid values of EC and relying on the IV)? Putting the header into the IV necessarily protects the header. This lets us have a savings of 16 bytes (no confounder) and 16 more bytes (no header added to the plaintext), and costs us 4 bytes (the integrity tag is 128 bits instead of 96 for the AES CTS HMAC-SHA1 enctypes), saving us a total of 28 bytes of overheade for wrap with confidentiality tokens. This is huge for small tokens, and a big performance improvement: less data to transmit, less to move around, and two fewer block operations, at no extra cost for protecting the header, plus it's now parallelizable, and the integrity tag computation is faster than HMAC-SHA-1. The whole header is 128 bits and doesn't fit in 96 bits, but there are five bytes that don't need protection, and if in a pinch we could squeeze two more bytes out of the header. So making the IV this is good enough: TOK_ID || Flags || 0xFF || SEND_SEQ The EC field is going to be a constant in all cases for these enctypes. And the RRC field has never needed integrity protection. That's the four bytes we drop from the header to form the IV. This leaves us with 32 bits of counter for the message data, which means 64GB wrap token w/ confidentiality max size. 64GB is plenty for this. (There's only three TOK_ID values of interest here, and only three flags bits used, so we could fold the TOK_ID into flags, leaving us with three bytes for whatever we want, if we needed them. But we don't need them.) Nico --=20 From nobody Tue Dec 8 14:46:15 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA20E1ACD3A for ; Tue, 8 Dec 2015 14:46:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQhg4PlUJd4d for ; Tue, 8 Dec 2015 14:46:12 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DC491ACCF6 for ; Tue, 8 Dec 2015 14:46:11 -0800 (PST) Received: by us.padl.com with ESMTP id tB8Mk20k015774; Tue, 8 Dec 2015 17:46:06 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Luke Howard X-Mailer: iPhone Mail (13C75) In-Reply-To: <20151208223656.GD23318@localhost> Date: Wed, 9 Dec 2015 09:46:01 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <7216FCF9-6F37-4D23-8A36-F75E7ED4EB7C@padl.com> References: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> <1D0FEA3E-A8D7-4702-B228-FAF697BB427A@padl.com> <5666640C.2050401@mit.edu> <20151208223656.GD23318@localhost> To: Nico Williams X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: BAYES_00,MIME_QP_LONG_LINE,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.2 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] AES-GCM for Kerberos GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 22:46:14 -0000 Note that in my proposal - based on IPSec - the entropy came from the last f= our bytes of the acceptor sub session key (having made that 20 instead of 16= bytes) so it wasn't sent in the clear, but I agree it probably adds no util= ity. It looks as if this exists in IPSec because keys may be reused, which w= e're asserting is not the case in the GSS profile. Sent from my iPhone > On 9 Dec 2015, at 09:36, Nico Williams wrote: >=20 > On Tue, Dec 08, 2015 at 04:47:21PM +1100, Luke Howard wrote: >>> On 8 Dec 2015, at 4:01 PM, Greg Hudson wrote: >>>> On 12/07/2015 07:28 PM, Luke Howard wrote: >>>> Nico doesn=E2=80=99t think this is worth worrying about (GCM spec says t= hat it=E2=80=99s >>>> OK to have a completely deterministic IV as long as it=E2=80=99s not re= used with >>>> the same key), but perhaps the extra entropy / consistency with >>>> TLS/IPsec is a good idea? >>>=20 >>> I agree with Nico; I think this is extra complexity we don't want or nee= d. >=20 > In particular: a deterministic IV construction is the key to preventing > key/IV reuse, _and_, we only need entropy in the key. >=20 > Entropy in the IV doesn't help security because whatever bits of it are > randomly chosen have to be sent in the clear as otherwise the peer won't > be able to reconstruct them. The IV cannot be secret for GSS because of > the out of sequence token delivery/consumption requirement (well, it's > an option, but one we want). >=20 > For an RFC3961 octet stream application like AFS' rx the initial IV > could be secret and non-deterministic, thereafter just a counter. In > this case entropy in the IV might increase security, but we don't need > that to make the enctype secure for GSS. >=20 > Entropy in the IV doesn't help UNLESS you just cannot construct a > deterministic IV. Since here we can, we should not have any entropy in > the IV. >=20 >> OK. Are you OK with not protecting the token header in the MAC (i.e. >> asserting valid values of EC and relying on the IV)? >=20 > Putting the header into the IV necessarily protects the header. >=20 > This lets us have a savings of 16 bytes (no confounder) and 16 more > bytes (no header added to the plaintext), and costs us 4 bytes (the > integrity tag is 128 bits instead of 96 for the AES CTS HMAC-SHA1 > enctypes), saving us a total of 28 bytes of overheade for wrap with > confidentiality tokens. This is huge for small tokens, and a big > performance improvement: less data to transmit, less to move around, and > two fewer block operations, at no extra cost for protecting the header, > plus it's now parallelizable, and the integrity tag computation is > faster than HMAC-SHA-1. >=20 > The whole header is 128 bits and doesn't fit in 96 bits, but there are > five bytes that don't need protection, and if in a pinch we could > squeeze two more bytes out of the header. So making the IV this is good > enough: >=20 > TOK_ID || Flags || 0xFF || SEND_SEQ >=20 > The EC field is going to be a constant in all cases for these enctypes. > And the RRC field has never needed integrity protection. That's the > four bytes we drop from the header to form the IV. >=20 > This leaves us with 32 bits of counter for the message data, which means > 64GB wrap token w/ confidentiality max size. 64GB is plenty for this. >=20 > (There's only three TOK_ID values of interest here, and only three flags > bits used, so we could fold the TOK_ID into flags, leaving us with three > bytes for whatever we want, if we needed them. But we don't need them.) >=20 > Nico > --=20 From nobody Tue Dec 8 16:11:54 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C3F1B29AC for ; Tue, 8 Dec 2015 16:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35ZtqDokcaaA for ; Tue, 8 Dec 2015 16:11:52 -0800 (PST) Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1E81B29AA for ; Tue, 8 Dec 2015 16:11:52 -0800 (PST) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 0412636006B; Tue, 8 Dec 2015 16:11:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=xk0IJzm8ZF/p/F 4CtZ0QkjCw1oY=; b=ndQ9sJ549yPtiOSL5GxEpNu3YUJAU0qYkUZq7K0MD0Qov9 zVAXChMq4x+//ckIgzOwt7IMX7sfYHEcHrXx3af30FlIkGttuSL0TUscM64sdsI0 ytK2vNHz9/8EZuYjNzNp/HIzipjH/+VZwQcA7YJxvwS6vPPJjTzVByNDvz2RI= Received: from localhost (108-207-244-100.lightspeed.austtx.sbcglobal.net [108.207.244.100]) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPA id 83E6A36006A; Tue, 8 Dec 2015 16:11:51 -0800 (PST) Date: Tue, 8 Dec 2015 18:11:50 -0600 From: Nico Williams To: Luke Howard Message-ID: <20151209001149.GE23318@localhost> References: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> <1D0FEA3E-A8D7-4702-B228-FAF697BB427A@padl.com> <5666640C.2050401@mit.edu> <20151208223656.GD23318@localhost> <7216FCF9-6F37-4D23-8A36-F75E7ED4EB7C@padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7216FCF9-6F37-4D23-8A36-F75E7ED4EB7C@padl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] AES-GCM for Kerberos GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 00:11:53 -0000 On Wed, Dec 09, 2015 at 09:46:01AM +1100, Luke Howard wrote: > Note that in my proposal - based on IPSec - the entropy came from the > last four bytes of the acceptor sub session key (having made that 20 But in that case no new entropy was contributed anyways... > instead of 16 bytes) so it wasn't sent in the clear, but I agree it > probably adds no utility. It looks as if this exists in IPSec because > keys may be reused, which we're asserting is not the case in the GSS > profile. Correct. Senders never reuse sequence numbers; session keys are chosen randomly, and hopefully never reused. Initial sequence numbers are also chosen randomly (so, in fact, we get some entropy in the IV after all! just indirectly), though monotonically increasing thereafter. A bad RNG could result in the same session keys (and initial sequence numbers) being chosen repeatedly, but only sessions will be compromised, not long-term keys nor Ticket session keys. IPsec is a very different beast. Nico -- From nobody Tue Dec 8 19:04:58 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC991A885B for ; Tue, 8 Dec 2015 19:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icyzBgLiWIZM for ; Tue, 8 Dec 2015 19:04:56 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B511A8851 for ; Tue, 8 Dec 2015 19:04:55 -0800 (PST) X-AuditID: 1209190c-f79c96d00000038e-93-56679a563de6 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 01.4F.00910.65A97665; Tue, 8 Dec 2015 22:04:54 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id tB934riq020938; Tue, 8 Dec 2015 22:04:54 -0500 Received: from [18.101.8.83] (vpn-18-101-8-83.mit.edu [18.101.8.83]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tB934nZV029916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 8 Dec 2015 22:04:52 -0500 To: Luke Howard , "Peck, Michael A" References: <20151203182416.14249.59890.idtracker@ietfa.amsl.com> <8BBA724D-905D-4B7D-BE87-A8748D8A8F3E@mitre.org> From: Greg Hudson Message-ID: <56679A51.3030700@mit.edu> Date: Tue, 8 Dec 2015 22:04:49 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmleLIzCtJLcpLzFFi42IRYrdT1w2blR5mMH+eusXRzatYLO5e+s9u cfrWc2YHZo8lS34yebxtuMruMffDNJYA5igum5TUnMyy1CJ9uwSujI4l2gVfWSrmTLvF2sDY wdLFyMkhIWAisXDhXCYIW0ziwr31bF2MXBxCAouZJM40bGcDSQgJbGCUuLmPDyJxgEli370m oAQHh7CAj8TVN94gNSICrhKrju9ggqhZxigx78xJRpAEs4C6xNHnTWCD2ASUJdbv38oC0ssr oCYxdacmSJhFQEXi29qnrCBhUYEIiUU7MkHCvAKCEidnPgG7k1PARuLK7gNMMBP/zLvEDGHL SzRvnc08gVFwFpKWWUjKZiEpW8DIvIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXUC83s0QvNaV0 EyMonDkleXYwvjmodIhRgINRiYf3gkt6mBBrYllxZe4hRkkOJiVRXuN2oBBfUn5KZUZicUZ8 UWlOavEhRgkOZiURXq1aoBxvSmJlVWpRPkxKmoNFSZx37hffMCGB9MSS1OzU1ILUIpisDAeH kgTv0alAjYJFqempFWmZOSUIaSYOTpDhPEDD42aADC8uSMwtzkyHyJ9i1OVY8OP2WiYhlrz8 vFQpcV7rmUBFAiBFGaV5cHPAaSiVI/gVozjQW8K8zSDreIApDG7SK6AlTEBLol4mgywpSURI STUwVtzYWDXt+ePatz9fiRiGsDGWn1zjtyVsToqzYQDHxq95h8/+6JpYULGfy1bg0dPlL3eK mVyq65gWECVtfntGQrBqRLqZt9v6hp2ubUc9tp39/6qTe9ah3r0/lyRLlzS4PtCw1j9uJrez +tft0FM/O0s7C6L8/waHz9BwTWDLNNc515q1Z+pRJZbijERDLeai4kQAB8jXnB4DAAA= Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-07.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 03:04:58 -0000 On 12/03/2015 10:07 PM, Luke Howard wrote: > Hi Mike, > > Thanks for this. I’ve updated the Heimdal implementation with the PRF changes and verified all of the test vectors. > > https://github.com/heimdal/heimdal/tree/lukeh/aes-cts-hmac-sha2 I have an implementation for MIT krb5 at: https://github.com/greghudson/krb5/tree/aes-sha2 (No guarantee of commit ID stability, and the branch will likely go away if and when it is merged to the upstream master branch.) Obviously no implementation can be production-ready until we have enctype and checksumtype assignments. All of the test vectors are verified. From nobody Tue Dec 8 22:09:57 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0717D1ACE27 for ; Tue, 8 Dec 2015 22:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNaKzBBfc8cg for ; Tue, 8 Dec 2015 22:09:54 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2996B1ACE1D for ; Tue, 8 Dec 2015 22:09:45 -0800 (PST) Received: by us.padl.com with ESMTP id tB969dPi030408; Wed, 9 Dec 2015 01:09:42 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luke Howard In-Reply-To: <56679A51.3030700@mit.edu> Date: Wed, 9 Dec 2015 17:09:37 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151203182416.14249.59890.idtracker@ietfa.amsl.com> <8BBA724D-905D-4B7D-BE87-A8748D8A8F3E@mitre.org> <56679A51.3030700@mit.edu> To: Greg Hudson X-Mailer: Apple Mail (2.3096.5) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.9 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-07.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 06:09:56 -0000 > On 9 Dec 2015, at 2:04 PM, Greg Hudson wrote: >=20 > On 12/03/2015 10:07 PM, Luke Howard wrote: >> Hi Mike, >>=20 >> Thanks for this. I=E2=80=99ve updated the Heimdal implementation with = the PRF changes and verified all of the test vectors. >>=20 >> https://github.com/heimdal/heimdal/tree/lukeh/aes-cts-hmac-sha2 >=20 > I have an implementation for MIT krb5 at: >=20 > https://github.com/greghudson/krb5/tree/aes-sha2 >=20 > (No guarantee of commit ID stability, and the branch will likely go = away > if and when it is merged to the upstream master branch.) Obviously no > implementation can be production-ready until we have enctype and > checksumtype assignments. All of the test vectors are verified. I have verified: * MIT kinit against Heimdal KDC * Heimdal gss-client against MIT gss-server Greg =E2=80=93 what do you think about default enctype ordering, should = it be preferred over the 3962 enctypes? =E2=80=94 Luke= From nobody Wed Dec 9 01:37:59 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE871B2B01 for ; Wed, 9 Dec 2015 01:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.334 X-Spam-Level: X-Spam-Status: No, score=0.334 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBYQypGs5vEU for ; Wed, 9 Dec 2015 01:37:57 -0800 (PST) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5131B2B61 for ; Wed, 9 Dec 2015 01:37:56 -0800 (PST) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 1C89A2005E513; Wed, 9 Dec 2015 01:37:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=dwPEf1d42WKxWk8nqVgtNt+MDqA=; b=klOf4qghYK9 coxGcD1x36ueFX5w++vJm5TeIBXVin7Lf0jng1cSCNsdFJpmW05PE7Inmfsr8byC zmkVJDJlMhtfItvqQpOepRWw4xZS9TxWHxighH42gVjq2mDgJFklg2IRB2Dj3rzz CDAsbbm4r90ieMalUm665BJkFDlHPbGU= Received: from localhost (108-207-244-100.lightspeed.austtx.sbcglobal.net [108.207.244.100]) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPA id B96862005E511; Wed, 9 Dec 2015 01:37:55 -0800 (PST) Date: Wed, 9 Dec 2015 03:37:54 -0600 From: Nico Williams To: "Henry B (Hank) Hotz, CISSP" Message-ID: <20151209093754.GE3198@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "kitten@ietf.org " Subject: Re: [kitten] New EncTypes? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 09:37:58 -0000 On Wed, Nov 18, 2015 at 04:20:41PM -0800, Henry B (Hank) Hotz, CISSP wrot= e: > It seems to be time to do housecleaning on algorithms selections. Is > anyone interested in adding a new enctype to Kerberos? Luke's working on AEAD enctypes. > Why (else)? Speaking strictly for myself, I=E2=80=99d like to see a > mandatory-to-implement enctype that shares *nothing* with the current > aes-sha1-hmac stuff. I=E2=80=99m speaking purely strategically and not = from > any mathematical suspicion of weakness. If someone discovers something > fundamentally wrong with the math behind SHA1 or AES, then it might > take out SHA2 or Camellia as well. It's hard not to share AES. Nowadays CPUs can do AES in constant time, very fast, in hardware. That's hard to pass up. Yes, AES in software is terrible for security, and an alternative would be nice for systems that don't have AES HW. > Just to throw some straw (just straw, not an actual strawman) on the > table, how about something that uses one of the European stream cipher > finalists with SHA-3? AEAD enctypes seem a lot more appealing to me. Luke's work will reduce the RFC4121/3962 overhead on GSS wrap tokens with confidentiality by 28 bytes, and will reduce the number of block operations by 2 blocks per wrap w/ conf token, as well as support parallelization (in principle anyways). Plus AEAD cipher modes can be quite fast. Nico --=20 From nobody Wed Dec 9 01:47:50 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181801B2B8D for ; Wed, 9 Dec 2015 01:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2fjTWGSKJP9 for ; Wed, 9 Dec 2015 01:47:48 -0800 (PST) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A347D1B2B8B for ; Wed, 9 Dec 2015 01:47:48 -0800 (PST) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 7130D2005E517; Wed, 9 Dec 2015 01:47:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=q/gpMTBg5EIfNc jqIOn1wDdqT/o=; b=azUwm37tfHMCrJ5UUMdsNb+YpRU+Kub+fRHn7ENE7RF/K3 zAK968EYY4UhsS//lTs/PpC8+SsnvtfYlX3NrrXMq+H0jH3H9aFsYzLSprkFco3a tCksEJQcbH6bL3pRu5aBE3Egyj+XPBYUWyo0wmZqse5vwIBYLK9ywhZ9QfjwU= Received: from localhost (108-207-244-100.lightspeed.austtx.sbcglobal.net [108.207.244.100]) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPA id 06DA62005E516; Wed, 9 Dec 2015 01:47:47 -0800 (PST) Date: Wed, 9 Dec 2015 03:47:47 -0600 From: Nico Williams To: Rick van Rein Message-ID: <20151209094746.GF3198@localhost> References: <564D7A8A.2070208@openfortress.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <564D7A8A.2070208@openfortress.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "kitten@ietf.org " Subject: Re: [kitten] New EncTypes? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 09:47:50 -0000 On Thu, Nov 19, 2015 at 08:30:18AM +0100, Rick van Rein wrote: > > It seems to be time to do housecleaning on algorithms selections. Is > > anyone interested in adding a new enctype to Kerberos? > > > One thing I would like to bring into any such discussion is that it > would be possible to use through PKCS #11, the de-facto standard for > storing keys on tokens, including hardware keys that will never share > keys directly but allow their use through the API. This extends the > range of possible uses for Kerberos, I think. It's kinda meaningless to use hardware tokens for Kerberos. On the KDC side you'd have to put the entire KDC in the token for it to be meaningful. You can leave the KDB outside, but now all KDB records have to be signed, and keys encrypted (the latter is generally supported, but the former would require significant rototilling). It's easier instead to harden a KDC, building it like a large HSM. On the service side (including the TGS), your hardware tokens had better be *fast* -- if not then forget it. A TGS can be slow, if the HW is slow, but throughput has to be reasonable, and total latency per-request below the point at which clients timeout. Hardware tokens make a lot more sense for PK-based protocols. If you really want HW tokens, then Kerberos is not for you. I'd be much more interested in working on a DANE-based mech_dh replacement than in working on putting a KDC in a token. Such a mech could have Kerberos-compatible principal naming and even attribute certificates to match authorization-data. Being PK- and DNSSEC-based would mean cross-realm functionality would be present from the get-go, and it'd mean that HW tokens would be meaningful from day one as well (well, as meaningful as they are with any PK today). > For instance, AES-CTS-HMAC uses plain standard AES and HMAC, and CTS can > be implemented in terms of standard CBC, so it ought to be possible to > implement with PKCS #11 (not that I've already actually tried, but it > looks possible). Solaris/Illumos implements CTS in terms of CBC, so, yes, it can be done. It takes up to three calls to CBC, so HW latency can be a problem. (See above remarks.) Nico -- From nobody Wed Dec 9 01:50:33 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90EE81A0024 for ; Wed, 9 Dec 2015 01:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYpVpCHCz38F for ; Wed, 9 Dec 2015 01:50:23 -0800 (PST) Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7A91A0016 for ; Wed, 9 Dec 2015 01:50:23 -0800 (PST) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 5C02959405E; Wed, 9 Dec 2015 01:50:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=QEuR8p1awYC7g/oiFhYjgFFcyKs=; b=prbvoayw6oh AGo4A4tjG5j6WvozFadCbiyknJGGid65PE62Ip7nfIlrZj4fJ7oyURaw8RnKea4A EGrJV27MSdxXvRcuVf+rvNPh09c0w1DrnQGt+dSecubG7nmBSxh57VQUS8REAden eimdkj/NqKFhSvF6Lt2/2+T7eCB1zEc0= Received: from localhost (108-207-244-100.lightspeed.austtx.sbcglobal.net [108.207.244.100]) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPA id E895D594057; Wed, 9 Dec 2015 01:50:22 -0800 (PST) Date: Wed, 9 Dec 2015 03:50:22 -0600 From: Nico Williams To: Greg Hudson Message-ID: <20151209095021.GG3198@localhost> References: <63860D22-138C-430F-B615-06CBB14654CC@oxy.edu> <56201FF6.4070902@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <56201FF6.4070902@mit.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Non-Password Password Change X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 09:50:32 -0000 On Thu, Oct 15, 2015 at 05:51:50PM -0400, Greg Hudson wrote: > On 10/15/2015 03:59 PM, Henry B (Hank) Hotz, CISSP wrote: > > There=E2=80=99s been work on improved password change protocols, but = I=E2=80=99m not sure how much actually completed. I also remember once su= ggesting that loading a KDB entry from a keytab file would be useful, at = least for handling cross-realm principals. >=20 > I believe the most recent work is: >=20 > https://tools.ietf.org/html/draft-ietf-krb-wg-kerberos-set-passwd-0= 8 >=20 > I vaguely recall an explicit decision not to continue with that work > because no one believed they were likely to implement it. Yes. > > Are there any password change protocols where you can supply the enct= ype and a key instead of a text password? >=20 > This is probably obvious, but any such facility allows the client to > circumvent password policies, and therefore usually require special > permissions. Roland Dowdeswell's krb5_admin has a method for setting principal keys with a multi-party DH exchange where the KDC is one of the parties. This works *very* well. I strongly recommend it. https://github.com/elr= ic1/ Nico --=20 From nobody Wed Dec 9 05:15:59 2015 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCF21A90E7; Wed, 9 Dec 2015 05:15:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151209131557.28382.98569.idtracker@ietfa.amsl.com> Date: Wed, 09 Dec 2015 05:15:57 -0800 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-08.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 13:15:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : AES Encryption with HMAC-SHA2 for Kerberos 5 Authors : Michael J. Jenkins Michael A. Peck Kelley W. Burgin Filename : draft-ietf-kitten-aes-cts-hmac-sha2-08.txt Pages : 17 Date : 2015-12-09 Abstract: This document specifies two encryption types and two corresponding checksum types for Kerberos 5. The new types use AES in CTS mode (CBC mode with ciphertext stealing) for confidentiality and HMAC with a SHA-2 hash for integrity. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-aes-cts-hmac-sha2-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 9 05:19:42 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A8D1A910B for ; Wed, 9 Dec 2015 05:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGtu-5gazswh for ; Wed, 9 Dec 2015 05:19:40 -0800 (PST) Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) by ietfa.amsl.com (Postfix) with ESMTP id 37B901A9106 for ; Wed, 9 Dec 2015 05:19:40 -0800 (PST) Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C00C36C01B4 for ; Wed, 9 Dec 2015 08:19:39 -0500 (EST) Received: from imshyb02.MITRE.ORG (imshyb02.mitre.org [129.83.29.3]) by smtpvmsrv1.mitre.org (Postfix) with ESMTP id B22DB6C03EF for ; Wed, 9 Dec 2015 08:19:39 -0500 (EST) Received: from imshyb02.MITRE.ORG (129.83.29.3) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 9 Dec 2015 08:19:39 -0500 Received: from na01-bl2-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1130.7 via Frontend Transport; Wed, 9 Dec 2015 08:19:39 -0500 Received: from BY1PR09MB0869.namprd09.prod.outlook.com (10.162.144.143) by BY1PR09MB0869.namprd09.prod.outlook.com (10.162.144.143) with Microsoft SMTP Server (TLS) id 15.1.337.19; Wed, 9 Dec 2015 13:19:37 +0000 Received: from BY1PR09MB0869.namprd09.prod.outlook.com ([10.162.144.143]) by BY1PR09MB0869.namprd09.prod.outlook.com ([10.162.144.143]) with mapi id 15.01.0337.015; Wed, 9 Dec 2015 13:19:37 +0000 From: "Peck, Michael A" To: "kitten@ietf.org" Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-08.txt Thread-Index: AQHRMoPIJvi1cRkEEEuJaylhDqyD557CT6gA Date: Wed, 9 Dec 2015 13:19:37 +0000 Message-ID: <8EE5CA99-AE24-4C9A-9A01-26B3680BE288@mitre.org> References: <20151209131557.28382.98569.idtracker@ietfa.amsl.com> In-Reply-To: <20151209131557.28382.98569.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mpeck@mitre.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [128.29.194.169] x-microsoft-exchange-diagnostics: 1; BY1PR09MB0869; 5:J6jQqBnhaBt2rJDhU42nbmb5TKenfMwvOi4qcClqhnA9LRca/zhm/VNnO/dbZo4Ia0KpSJ8WFQOhnXuojLxZLVX1MD8vAEzYmmEmC2U4wOinWwPsncJSKbDG0CZSEIw00bVquxsIC5ZbpVANv2Pw6Q==; 24:H4AsDQolRMihToN4NYCK2qAZAU/+bh+KUhF4LdevmGwjdyGwN2K65EwMyE4gAPQSEXVUaoXhOYSBY9oPRQJQzLmw6hfw6pvPF+DB8VspHHI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR09MB0869; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:BY1PR09MB0869; BCL:0; PCL:0; RULEID:; SRVR:BY1PR09MB0869; x-forefront-prvs: 0785459C39 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(377424004)(189002)(164054003)(479174004)(24454002)(377454003)(5001960100002)(107886002)(10400500002)(110136002)(5004730100002)(81156007)(99286002)(97736004)(11100500001)(2501003)(15975445007)(2950100001)(102836003)(2900100001)(54356999)(76176999)(105586002)(3846002)(586003)(1096002)(50986999)(1220700001)(5008740100001)(6116002)(77096005)(2351001)(106116001)(106356001)(4001350100001)(450100001)(19580405001)(101416001)(19580395003)(87936001)(83716003)(83506001)(86362001)(230783001)(36756003)(92566002)(189998001)(40100003)(5002640100001)(122556002)(66066001)(82746002)(33656002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR09MB0869; H:BY1PR09MB0869.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: mitre.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2015 13:19:37.3766 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR09MB0869 X-OriginatorOrg: mitre.org Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-08.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 13:19:42 -0000 VGhpcyAtMDggZHJhZnQgaG9wZWZ1bGx5IGFkZHJlc3NlcyBHcmVn4oCZcyBmZWVkYmFjayAocmFu ZG9tLXRvLWtleSBmdW5jdGlvbiwgY2lwaGVyc3RhdGUgZGVmaW5pdGlvbikuDQoNClRoYW5rcywN Ck1pa2UNCg0KDQpPbiAxMi85LzE1LCA4OjE1IEFNLCAiS2l0dGVuIG9uIGJlaGFsZiBvZiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxraXR0ZW4tYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYg b2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3cm90ZToNCg0KPg0KPkEgTmV3IEludGVybmV0 LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJl Y3Rvcmllcy4NCj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29tbW9uIEF1dGhl bnRpY2F0aW9uIFRlY2hub2xvZ3kgTmV4dCBHZW5lcmF0aW9uIFdvcmtpbmcgR3JvdXAgb2YgdGhl IElFVEYuDQo+DQo+ICAgICAgICBUaXRsZSAgICAgICAgICAgOiBBRVMgRW5jcnlwdGlvbiB3aXRo IEhNQUMtU0hBMiBmb3IgS2VyYmVyb3MgNQ0KPiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogTWlj aGFlbCBKLiBKZW5raW5zDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBNaWNoYWVsIEEuIFBl Y2sNCj4gICAgICAgICAgICAgICAgICAgICAgICAgIEtlbGxleSBXLiBCdXJnaW4NCj4JRmlsZW5h bWUgICAgICAgIDogZHJhZnQtaWV0Zi1raXR0ZW4tYWVzLWN0cy1obWFjLXNoYTItMDgudHh0DQo+ CVBhZ2VzICAgICAgICAgICA6IDE3DQo+CURhdGUgICAgICAgICAgICA6IDIwMTUtMTItMDkNCj4N Cj5BYnN0cmFjdDoNCj4gICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0d28gZW5jcnlwdGlvbiB0 eXBlcyBhbmQgdHdvIGNvcnJlc3BvbmRpbmcNCj4gICBjaGVja3N1bSB0eXBlcyBmb3IgS2VyYmVy b3MgNS4gIFRoZSBuZXcgdHlwZXMgdXNlIEFFUyBpbiBDVFMgbW9kZQ0KPiAgIChDQkMgbW9kZSB3 aXRoIGNpcGhlcnRleHQgc3RlYWxpbmcpIGZvciBjb25maWRlbnRpYWxpdHkgYW5kIEhNQUMgd2l0 aA0KPiAgIGEgU0hBLTIgaGFzaCBmb3IgaW50ZWdyaXR5Lg0KPg0KPg0KPlRoZSBJRVRGIGRhdGF0 cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYta2l0dGVuLWFlcy1jdHMtaG1hYy1zaGEyLw0KPg0K PlRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWtpdHRlbi1hZXMtY3RzLWhtYWMtc2hhMi0w OA0KPg0KPkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoN Cj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1raXR0ZW4tYWVz LWN0cy1obWFjLXNoYTItMDgNCj4NCj4NCj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+dW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y Zy4NCj4NCj5JbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBG VFAgYXQ6DQo+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4NCj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPktpdHRlbiBtYWlsaW5n IGxpc3QNCj5LaXR0ZW5AaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2tpdHRlbg0K From nobody Wed Dec 9 14:47:04 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6C71B2F45 for ; Wed, 9 Dec 2015 14:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JpGAidMLasb for ; Wed, 9 Dec 2015 14:47:02 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017431A924C for ; Wed, 9 Dec 2015 14:47:01 -0800 (PST) X-AuditID: 12074425-f793c6d000006975-51-5668af64d3a1 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id BD.19.26997.46FA8665; Wed, 9 Dec 2015 17:47:00 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id tB9Mkxba012455; Wed, 9 Dec 2015 17:47:00 -0500 Received: from [18.101.8.248] (vpn-18-101-8-248.mit.edu [18.101.8.248]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tB9MkvfJ023428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 9 Dec 2015 17:46:59 -0500 To: "Peck, Michael A" , "kitten@ietf.org" References: <20151209131557.28382.98569.idtracker@ietfa.amsl.com> <8EE5CA99-AE24-4C9A-9A01-26B3680BE288@mitre.org> From: Greg Hudson Message-ID: <5668AF61.60200@mit.edu> Date: Wed, 9 Dec 2015 17:46:57 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <8EE5CA99-AE24-4C9A-9A01-26B3680BE288@mitre.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixG6nopuyPiPMYNd1FYujm1exWJy+9ZzZ gcljyZKfTB5vG66yBzBFcdmkpOZklqUW6dslcGW8en2DueAWY0XTlansDYxbGbsYOTkkBEwk ni2bxg5hi0lcuLeerYuRi0NIYDGTxPMljUwQzgZGieZVM1khnMNMEit/bWEGaREW8JE42rIK yObgEAGyH65yBQkLCZRIPF53hAnEZhNQlli/fysLiM0roCLR+3EG2DYWILvn5yQWkFZRgQiJ RTsyIUoEJU7OfAJWzilgK/H24ikwm1lAXeLPvEvMELa8RPPW2cwTGAVmIWmZhaRsFpKyBYzM qxhlU3KrdHMTM3OKU5N1i5MT8/JSi3Qt9HIzS/RSU0o3MYLD1EV1B+OEQ0qHGAU4GJV4eC+4 pIcJsSaWFVfmHmKU5GBSEuW9uTgjTIgvKT+lMiOxOCO+qDQntfgQowQHs5IIb2gnUI43JbGy KrUoHyYlzcGiJM4794tvmJBAemJJanZqakFqEUxWhoNDSYLXZR1Qo2BRanpqRVpmTglCmomD E2Q4D9DwkLUgw4sLEnOLM9Mh8qcYdTkW/Li9lkmIJS8/L1VKnPctSJEASFFGaR7cHHB6SeX4 8YpRHOgtYV42kHU8wNQEN+kV0BImoCVfrqSDLClJREhJNTCWcws9DbZz5PhVeSY8U15TOJ95 VXZEW8ykNYvU37XZfX1ZKLLufV5MrJTEjFcHF320WHr2RoTq6oNsgYarQ877eS21Ltc8r/J2 tm7QKgVnv9I4y63hwjIVor52aS/lP/GnsqrtVuKX4+VKTt/3Ju9pUvZ6jasahtZMd6Mf3/Xb cbG00EZES4mlOCPRUIu5qDgRAKQN07oKAwAA Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-08.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 22:47:03 -0000 On 12/09/2015 08:19 AM, Peck, Michael A wrote: > This -08 draft hopefully addresses Greg’s feedback (random-to-key function, cipherstate definition). I think these changes are correct and address my feedback. From nobody Thu Dec 10 15:01:14 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5901B2D3C for ; Thu, 10 Dec 2015 15:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNEthYbSPFNN for ; Thu, 10 Dec 2015 15:01:10 -0800 (PST) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CDA51B2D6B for ; Thu, 10 Dec 2015 15:01:02 -0800 (PST) Received: from airhead.local ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id rz0y1r00F10HQrX01z0zdU; Fri, 11 Dec 2015 00:01:01 +0100 Message-ID: <566A0429.4010602@openfortress.nl> Date: Fri, 11 Dec 2015 00:00:57 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Nico Williams References: <564D7A8A.2070208@openfortress.nl> <20151209094746.GF3198@localhost> In-Reply-To: <20151209094746.GF3198@localhost> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Cc: "kitten@ietf.org " Subject: Re: [kitten] New EncTypes? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 23:01:12 -0000 Hi Nico, I was thinking of client-side tokens, not the KDC. > It's kinda meaningless to use hardware tokens for Kerberos. Symmetric keys reside on two ends, but the client will be much weaker in its protection than the KDC; a reason for using PKCS #11 on the client end is to uplift that level (and have better entropy than a password supplies). That would be an improvement even if the KDC was not changed at all. I agree that hardening the KDC can be pretty much comparable to hardening an HSM. > Hardware tokens make a lot more sense for PK-based protocols. If you > really want HW tokens, then Kerberos is not for you. Yes and no... it's not a one-dimensional choice between PK and KRB5. > I'd be much more interested in working on a DANE-based mech_dh > replacement than in working on putting a KDC in a token. I have a student working on that now :) and will send a project description/proposal to at least MIT krb, and perhaps also Kitten, sometime soon. > Such a mech > could have Kerberos-compatible principal naming and even attribute > certificates to match authorization-data. Being PK- and DNSSEC-based > would mean cross-realm functionality would be present from the get-go, > and it'd mean that HW tokens would be meaningful from day one as well > (well, as meaningful as they are with any PK today). PKINIT makes PK usable already, so I'm not sure why you bring DNSSEC/DANE in here? Do you want to improve on the cryptographic strength of the initial password to protect AS? Solaris/Illumos implements CTS in terms of CBC, so, yes, it can be done. It takes up to three calls to CBC, so HW latency can be a problem. (See above remarks.) Three is the total; encryption takes one CBC call, decryption takes two: https://github.com/arpa2/kerberos-pkcs11/blob/master/aes128-cts-pkcs11.c#L221 https://github.com/arpa2/kerberos-pkcs11/blob/master/aes128-cts-pkcs11.c#L236 https://github.com/arpa2/kerberos-pkcs11/blob/master/aes128-cts-pkcs11.c#L241 Thanks, -Rick From nobody Thu Dec 10 15:36:45 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CDF1A8A99 for ; Thu, 10 Dec 2015 15:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CttElObSiLda for ; Thu, 10 Dec 2015 15:36:41 -0800 (PST) Received: from homiemail-a95.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1B83A1B2EAA for ; Thu, 10 Dec 2015 15:36:34 -0800 (PST) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id CF2141E094; Thu, 10 Dec 2015 15:36:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Dxlz4GIrod+lGk WjZYIeGOvtZ4k=; b=MvaVevaPTWDg8HSFnqVP/udagi0wY3BkzLa0TfI2RX1uRP XI2Xg6Wy3rBquljb9S4n4D7mQ85ujcHCoroIthKlXFbttJdOD56OmpVIJCT07uhJ SHuxWWAkEw78olbqqtN4/kDWIwighE+2mtdu2/AArdcvro47vZtYarrFVVZbA= Received: from localhost (108-207-244-100.lightspeed.austtx.sbcglobal.net [108.207.244.100]) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPA id 475F91E059; Thu, 10 Dec 2015 15:36:33 -0800 (PST) Date: Thu, 10 Dec 2015 17:36:32 -0600 From: Nico Williams To: Rick van Rein Message-ID: <20151210233631.GP3198@localhost> References: <564D7A8A.2070208@openfortress.nl> <20151209094746.GF3198@localhost> <566A0429.4010602@openfortress.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <566A0429.4010602@openfortress.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "kitten@ietf.org " Subject: Re: [kitten] New EncTypes? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 23:36:43 -0000 On Fri, Dec 11, 2015 at 12:00:57AM +0100, Rick van Rein wrote: > I was thinking of client-side tokens, not the KDC. There's no need for KITTEN to be involved in making Kerberos clients use a token. > > I'd be much more interested in working on a DANE-based mech_dh > > replacement than in working on putting a KDC in a token. > > I have a student working on that now :) and will send a project > description/proposal to at least MIT krb, and perhaps also Kitten, > sometime soon. Oh, that's interesting. > > Such a mech > > could have Kerberos-compatible principal naming and even attribute > > certificates to match authorization-data. Being PK- and DNSSEC-based > > would mean cross-realm functionality would be present from the get-go, > > and it'd mean that HW tokens would be meaningful from day one as well > > (well, as meaningful as they are with any PK today). > > PKINIT makes PK usable already, so I'm not sure why you bring > DNSSEC/DANE in here? Do you want to improve on the cryptographic > strength of the initial password to protect AS? DNSSEC/DANE is to get a PKI. DNSSEC is a PKI, a true hierarchical one, and one using domainnames as issuer and end entity names. The WebPKI is not really hierarchical, doesn't deal well with domainnames, and has other shortcomings. Using DNSSEC/DANE means instant "PKCROSS" for a modern mech_dh. The key is to staple DNS responses that contain all the necessary RRs, with the trust chain mostly as additional RRs. Nico -- From nobody Thu Dec 10 16:12:09 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426841B3027 for ; Thu, 10 Dec 2015 16:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WUf3NwaatYH for ; Thu, 10 Dec 2015 16:12:06 -0800 (PST) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.201.169]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B93651B3004 for ; Thu, 10 Dec 2015 16:12:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 5D710F48E; Thu, 10 Dec 2015 19:12:03 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at mailout.easymail.ca Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlCojQkeoUXo; Thu, 10 Dec 2015 19:11:59 -0500 (EST) Received: from [192.168.1.180] (wsip-174-76-19-88.oc.oc.cox.net [174.76.19.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 12ACAF487; Thu, 10 Dec 2015 19:11:58 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Henry B (Hank) Hotz, CISSP" In-Reply-To: <566A0429.4010602@openfortress.nl> Date: Thu, 10 Dec 2015 16:11:57 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <564D7A8A.2070208@openfortress.nl> <20151209094746.GF3198@localhost> <566A0429.4010602@openfortress.nl> To: Rick van Rein X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "kitten@ietf.org " Subject: Re: [kitten] New EncTypes? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 00:12:08 -0000 > On Dec 10, 2015, at 3:00 PM, Rick van Rein = wrote: >=20 > Hi Nico, >=20 > I was thinking of client-side tokens, not the KDC. >=20 > Symmetric keys reside on two ends, but the client will be much weaker = in > its protection than the KDC; a reason for using PKCS #11 on the client > end is to uplift that level (and have better entropy than a password > supplies). That would be an improvement even if the KDC was not = changed > at all. I agree that hardening the KDC can be pretty much comparable = to > hardening an HSM. >> Hardware tokens make a lot more sense for PK-based protocols. If you >> really want HW tokens, then Kerberos is not for you. >=20 > Yes and no... it's not a one-dimensional choice between PK and KRB5. There=92s no reason you can=92t build a smart card that will do AES on = supplied data once unlocked with a PIN. Keys importable, but not = exportable. I think the right comparison is to a keytab, so it=92s not = even that radical. Agree that X.509/PKIX has a lot of distracting complexities (I=92m being = polite), and DNSSEC is a better PKI for us. I like the possibility of a = more scalable cross-realm alternative. The existing one is good for = small scale, like single-hop relationships.=20 Is there actually interest in a HSM/KDC combination? I toyed with the = idea once. . . More to the point of the thread, I=92m not sure any of these things = necessitate EncType or protocol changes. Defining a relationship between = DNSSEC and PKINIT/PKCROSS is a new area. While we=92re at it, could we = define the user=92s Principal to be a functional email address in DNSSEC = and make signed/encrypted email usable? I could argue that this is the = way things are supposed to work! Personal: hbhotz@oxy.edu Business: hhotz@securechannels.com From nobody Thu Dec 10 20:28:53 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192251A3BA6 for ; Thu, 10 Dec 2015 20:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdMR38LI0FNS for ; Thu, 10 Dec 2015 20:28:50 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1BA1A3BA3 for ; Thu, 10 Dec 2015 20:28:49 -0800 (PST) X-AuditID: 12074422-f79c46d000006aa7-76-566a510058e1 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 4C.28.27303.0015A665; Thu, 10 Dec 2015 23:28:48 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id tBB4SlKg026554; Thu, 10 Dec 2015 23:28:48 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tBB4SirL020341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Dec 2015 23:28:47 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id tBB4Sijv014124; Thu, 10 Dec 2015 23:28:44 -0500 (EST) Date: Thu, 10 Dec 2015 23:28:44 -0500 (EST) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20151209093754.GE3198@localhost> Message-ID: References: <20151209093754.GE3198@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-864784769-1449808124=:26829" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IR4hTV1mUIzAozmNSqaHF08yoWi1PXjrA5 MHm8PHWO0WPJkp9MAUxRXDYpqTmZZalF+nYJXBn7Vn5hLpjEXfH97g22BsYmzi5GTg4JAROJ 0+v2MkPYYhIX7q1nA7GFBBYzSTzfIdzFyAVkb2SUOHFtDzOEc4hJYsfc++wQVQ2MEu1P8kBs FgFtiQkNtxhBbDYBFYmZbzaCTRIR0JS4Pm8pmM0sYCmxd9FPpi5GDg5hAWWJF9+UQMKcAnoS N4+uZgKxeQUcJd42bWeEGB8jsebucrBVogI6Eqv3T2GBqBGUODnzCQvIGGaBAIlvK1QmMArO QpKZhZCZBbZXXaLxwVk2CFtb4v7NNrYFjCyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdE31cjNL 9FJTSjcxgkKa3UVpB+PPg0qHGAU4GJV4eD3YssKEWBPLiitzDzFKcjApifKeMgYK8SXlp1Rm JBZnxBeV5qQWH2KU4GBWEuF96QCU401JrKxKLcqHSUlzsCiJ88794hsmJJCeWJKanZpakFoE k5Xh4FCS4GUNAGoULEpNT61Iy8wpQUgzcXCCDOcBGv7AH2R4cUFibnFmOkT+FKOilDjvC5CE AEgiozQPrheccnYzqb5iFAd6RZjXE2QFDzBdwXW/AhrMBDT4y5V0kMEliQgpqQbGCRkf7dr2 rT7rFzC1yfSBvYp88RsFbhtXpV1K4VWHemynv+Opu/xSWbLa9dlvoAvXr7rWe3jaSeb4oOCy xnae1NR9d/I+eOlLVszmCmNob2JcXsi1NfmWa9rVZSW1Hp55LT9P8fT/LZ/evGTqbu+G39N9 5CvY79WqaP+VXsbCcc9iO+drHiWW4oxEQy3mouJEALDxJQcUAwAA Archived-At: Cc: "kitten@ietf.org " Subject: Re: [kitten] New EncTypes? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 04:28:52 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-864784769-1449808124=:26829 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 9 Dec 2015, Nico Williams wrote: > On Wed, Nov 18, 2015 at 04:20:41PM -0800, Henry B (Hank) Hotz, CISSP wrot= e: > > It seems to be time to do housecleaning on algorithms selections. Is > > anyone interested in adding a new enctype to Kerberos? > > Luke's working on AEAD enctypes. > > > Why (else)? Speaking strictly for myself, I=E2=80=99d like to see a > > mandatory-to-implement enctype that shares *nothing* with the current > > aes-sha1-hmac stuff. I=E2=80=99m speaking purely strategically and not = from > > any mathematical suspicion of weakness. If someone discovers something > > fundamentally wrong with the math behind SHA1 or AES, then it might > > take out SHA2 or Camellia as well. > > It's hard not to share AES. Nowadays CPUs can do AES in constant time, > very fast, in hardware. That's hard to pass up. > > Yes, AES in software is terrible for security, and an alternative would > be nice for systems that don't have AES HW. You don't see potential in a chacha/poly scheme? Not that I'm volunteering to write the draft, mind you... -Ben ---559023410-864784769-1449808124=:26829-- From nobody Thu Dec 10 20:31:01 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956C81A6EED for ; Thu, 10 Dec 2015 20:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52WppdEZ-CCs for ; Thu, 10 Dec 2015 20:30:58 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A45F1A6EE2 for ; Thu, 10 Dec 2015 20:30:58 -0800 (PST) X-AuditID: 1209190f-f79d06d000004b20-33-566a518092db Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id F5.A4.19232.0815A665; Thu, 10 Dec 2015 23:30:57 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id tBB4UuaW008195; Thu, 10 Dec 2015 23:30:56 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tBB4Ur4Q020886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Dec 2015 23:30:55 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id tBB4UqQI014402; Thu, 10 Dec 2015 23:30:52 -0500 (EST) Date: Thu, 10 Dec 2015 23:30:52 -0500 (EST) From: Benjamin Kaduk To: "Henry B (Hank) Hotz, CISSP" In-Reply-To: Message-ID: References: <564D7A8A.2070208@openfortress.nl> <20151209094746.GF3198@localhost> <566A0429.4010602@openfortress.nl> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1576618870-1449808252=:26829" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IRYrdT0W0MzAozeH2c0eLjvYUsFkc3r2Jx YPJYsuQnk8fWpr/MAUxRXDYpqTmZZalF+nYJXBk9O9azFOzgrFi/YiNbA+Nd9i5GTg4JAROJ V2uWMULYYhIX7q1n62Lk4hASWMwk0dW6jRHC2cgocfzAZ2YI5xCTxLkT7awQTgOjRPPp1yxd jBwcLALaEk9Pgo1iE1CRmPlmIxuILSJgKDF95URWEJtZwFJi76KfTCDlwgLKEi++KYGEOQWs Jc69msgMYvMKOEq0nP8Gtesio8TK1jlgvaICOhKr909hgSgSlDg58wkLxMxAidfP+tgmMArO QpKahSQFYetJvPo3nxHC1pa4f7ONbQEjyypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdE73czBK9 1JTSTYyg0OaU5N/B+O2g0iFGAQ5GJR7eBRxZYUKsiWXFlbmHGCU5mJREeU8ZA4X4kvJTKjMS izPii0pzUosPMUpwMCuJ8L50AMrxpiRWVqUW5cOkpDlYlMR5537xDRMSSE8sSc1OTS1ILYLJ ynBwKEnw7gwAahQsSk1PrUjLzClBSDNxcIIM5wEa/sAfZHhxQWJucWY6RP4Uo6KUOO81kGYB kERGaR5cLzj17GZSfcUoDvSKMC8/SBUPMG3Bdb8CGswENPjLlXSQwSWJCCmpBkaH3MAM+VeS 7zfxSKionu3sdZgU6Pz7/r7rB3h7uh96zFd1/rHBbLqCAI9Jdb1d0upF04sPRnzaYJlzc8XU W8eXfXWQKLg8s6CbZ2uvN8vSo7Mfdt2TkmrQTI4t+rvpK6t7mi+j7MsN1nVWl0yb9c+d//uj 63n2tE9s6XbHV7OWXcl+6M/wI1OJpTgj0VCLuag4EQCbxZc0GAMAAA== Archived-At: Cc: "kitten@ietf.org " Subject: Re: [kitten] New EncTypes? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 04:30:59 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1576618870-1449808252=:26829 Content-Type: TEXT/PLAIN; charset=windows-1252 Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 10 Dec 2015, Henry B (Hank) Hotz, CISSP wrote: > > More to the point of the thread, I=92m not sure any of these things > necessitate EncType or protocol changes. Defining a relationship between > DNSSEC and PKINIT/PKCROSS is a new area. While we=92re at it, could we > define the user=92s Principal to be a functional email address in DNSSEC > and make signed/encrypted email usable? I could argue that this is the > way things are supposed to work! I have not been following particularly closely, but I thought there was a lot of trouble finding a reasonable way to present email addresses in the DNS and get continuity of keying -- the DNS administrator may not have a good connection to where the user's key gets set, etc.. I forget where this discussion was going on, though ... maybe perpass, though that doesn't quite feel right. -Ben ---559023410-1576618870-1449808252=:26829-- From nobody Thu Dec 10 23:26:31 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7896A1A8AA4 for ; Thu, 10 Dec 2015 23:26:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBurmu3tfhkZ for ; Thu, 10 Dec 2015 23:26:28 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 116B71A8A82 for ; Thu, 10 Dec 2015 23:26:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7A2ECBE50; Fri, 11 Dec 2015 07:26:25 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id od0tYq0u1EOZ; Fri, 11 Dec 2015 07:26:24 +0000 (GMT) Received: from [127.0.0.1] (unknown [86.46.18.60]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C14E2BE47; Fri, 11 Dec 2015 07:26:23 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449818784; bh=nH2D5eDLsSS6ZwtLfhadJKqFD+vrI+id9MI3RQw37XA=; h=To:Cc:From:Subject:In-Reply-To:References:Date:From; b=UPmwU/+ya7yinosGPM6gi3bO+BbjJgd+yQ91RFBB/+B08P5Oa3fW1GGbJTmbxLufO OKbQL6Y3bV97Klen0b2ZiitDuJzANuCi6dlx1sJaSAi8DNY+96ePmPSn7yPWJ5cT3V GKDLBdd1Ii+XcgiqAkH/d8zAwrN73mYcECAKbHys= X-Priority: 3 To: kaduk@MIT.EDU From: stephen.farrell@cs.tcd.ie In-Reply-To: References: <564D7A8A.2070208@openfortress.nl> <20151209094746.GF3198@localhost> <566A0429.4010602@openfortress.nl> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Date: Fri, 11 Dec 2015 07:26:22 +0000 Message-ID: MIME-Version: 1.0 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] New EncTypes? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 07:26:30 -0000 DQoNCk9uIEZyaSBEZWMgMTEgMDQ6MzA6NTIgMjAxNSBHTVQsIEJlbmphbWluIEthZHVrIHdyb3Rl Og0KPiBPbiBUaHUsIDEwIERlYyAyMDE1LCBIZW5yeSBCIChIYW5rKSBIb3R6LCBDSVNTUCB3cm90 ZToNCj4gDQo+ID4NCj4gPiBNb3JlIHRvIHRoZSBwb2ludCBvZiB0aGUgdGhyZWFkLCBJ4oCZbSBu b3Qgc3VyZSBhbnkgb2YgdGhlc2UgdGhpbmdzDQo+ID4gbmVjZXNzaXRhdGUgRW5jVHlwZSBvciBw cm90b2NvbCBjaGFuZ2VzLiBEZWZpbmluZyBhIHJlbGF0aW9uc2hpcCBiZXR3ZWVuDQo+ID4gRE5T U0VDIGFuZCBQS0lOSVQvUEtDUk9TUyBpcyBhIG5ldyBhcmVhLiBXaGlsZSB3ZeKAmXJlIGF0IGl0 LCBjb3VsZCB3ZQ0KPiA+IGRlZmluZSB0aGUgdXNlcuKAmXMgUHJpbmNpcGFsIHRvIGJlIGEgZnVu Y3Rpb25hbCBlbWFpbCBhZGRyZXNzIGluIEROU1NFQw0KPiA+IGFuZCBtYWtlIHNpZ25lZC9lbmNy eXB0ZWQgZW1haWwgdXNhYmxlPyBJIGNvdWxkIGFyZ3VlIHRoYXQgdGhpcyBpcyB0aGUNCj4gPiB3 YXkgdGhpbmdzIGFyZSBzdXBwb3NlZCB0byB3b3JrIQ0KPiANCj4gSSBoYXZlIG5vdCBiZWVuIGZv bGxvd2luZyBwYXJ0aWN1bGFybHkgY2xvc2VseSwgYnV0IEkgdGhvdWdodCB0aGVyZSB3YXMgYQ0K PiBsb3Qgb2YgdHJvdWJsZSBmaW5kaW5nIGEgcmVhc29uYWJsZSB3YXkgdG8gcHJlc2VudCBlbWFp bCBhZGRyZXNzZXMgaW4gdGhlDQo+IEROUyBhbmQgZ2V0IGNvbnRpbnVpdHkgb2Yga2V5aW5nIC0t IHRoZSBETlMgYWRtaW5pc3RyYXRvciBtYXkgbm90IGhhdmUgYQ0KPiBnb29kIGNvbm5lY3Rpb24g dG8gd2hlcmUgdGhlIHVzZXIncyBrZXkgZ2V0cyBzZXQsIGV0Yy4uDQo+IA0KPiBJIGZvcmdldCB3 aGVyZSB0aGlzIGRpc2N1c3Npb24gd2FzIGdvaW5nIG9uLCB0aG91Z2ggLi4uIG1heWJlIHBlcnBh c3MsDQo+IHRob3VnaCB0aGF0IGRvZXNuJ3QgcXVpdGUgZmVlbCByaWdodC4NCj4NCg0KREFORQ0K DQpTLg0KDQogDQo+IC1CZQ== From nobody Fri Dec 11 03:02:23 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9CFB1A8886 for ; Fri, 11 Dec 2015 03:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qyp0F9H7WEeL for ; Fri, 11 Dec 2015 03:02:18 -0800 (PST) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 707E41A887F for ; Fri, 11 Dec 2015 03:02:17 -0800 (PST) Received: from airhead.local ([83.161.146.46]) by smtp-cloud6.xs4all.net with ESMTP id sB2C1r00M10HQrX01B2Dpq; Fri, 11 Dec 2015 12:02:16 +0100 Message-ID: <566AAD32.7040707@openfortress.nl> Date: Fri, 11 Dec 2015 12:02:10 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "Henry B (Hank) Hotz, CISSP" References: <564D7A8A.2070208@openfortress.nl> <20151209094746.GF3198@localhost> <566A0429.4010602@openfortress.nl> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "kitten@ietf.org " Subject: Re: [kitten] New EncTypes? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 11:02:21 -0000 Hi Henry, > I like the possibility of a more scalable cross-realm alternative. The > existing one is good for small scale, like single-hop relationships. > I will put it up soon, and sounds like I should also post that MIT krb5 project here. Writing to do for me... > Is there actually interest in a HSM/KDC combination? I toyed with the > idea once. . . > It's a design alternative I'm looking into for InternetWide.org identity management. So, I'm also toying with it and thought when discussing new enctypes it would be good to bring up as a potential avenue. As for email-style names, interesting, we generally look at the concept of a NAI, RFC 7542. The difference being, it's not necessarily possible to send email to this user@domain.name style address. We defined general patterns for those as well, http://donai.arpa2.net/selector.html Cheers, -Rick From nobody Fri Dec 11 08:53:04 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63EC1B2D2B for ; Fri, 11 Dec 2015 08:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.109 X-Spam-Level: X-Spam-Status: No, score=0.109 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Z86nKsly08k for ; Fri, 11 Dec 2015 08:52:56 -0800 (PST) Received: from sequoia-grove.secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D2731B2D23 for ; Fri, 11 Dec 2015 08:52:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1449852750; x=1450457550; i=jaltman@secure-endpoints.com; q=dns/txt; h=VBR-Info:Subject:To: References:From:Openpgp:Organization:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type; bh=3e0X+kU2H5Lr4ZeWBKTVOW 1Sn12HF7Tvq0+D7/rEvB8=; b=om6jrkr52gQdMHPU6XhdbqTVf+5mofu/nULlcU wbL6uEuWEzEaqpf3u3QTYnM1A15E3d/FV3hoNCq28yhWQBQHFOKfpJzJRH2ozV+x i0lJzICREEGwdo70AUdIeG/2umMKhcV+IFigytlcb8gQPixHyJ3vh7ao1/RUmeUs +jPzg= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Fri, 11 Dec 2015 11:52:30 -0500 X-Spam-Processed: sequoia-grove.secure-endpoints.com, Fri, 11 Dec 2015 11:52:29 -0500 Received: from [x.x.x.x] by secure-endpoints.com (Cipher TLSv1:AES-SHA:256) (MDaemon PRO v15.5.2) with ESMTPSA id md50001002133.msg for ; Fri, 11 Dec 2015 11:52:28 -0500 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-MDArrival-Date: Fri, 11 Dec 2015 11:52:28 -0500 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=178744409f=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org To: kitten@ietf.org References: <20151209093754.GE3198@localhost> From: Jeffrey Altman Openpgp: id=FA444AF197F449B24CF3E699F77A735592B69A04; url=http://pgp.mit.edu Organization: Secure Endpoints Inc. Message-ID: <566AFF46.6080504@secure-endpoints.com> Date: Fri, 11 Dec 2015 11:52:22 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010809020204050607040309" Archived-At: Subject: Re: [kitten] New EncTypes? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 16:52:57 -0000 This is a cryptographically signed message in MIME format. --------------ms010809020204050607040309 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/10/2015 11:28 PM, Benjamin Kaduk wrote: > > You don't see potential in a chacha/poly scheme? Not that I'm > volunteering to write the draft, mind you... I would like to see a chacha/poly enctype but I'm not going to fund its development in the short term. It would be good to have a non-AES enctype in our back pocket even if we aren't using it regularly today. Jeffrey Altman --------------ms010809020204050607040309 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DV0wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0GCSqGSIb3DQEBBQUAMIHKMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9y IGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGlj IFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEwMDAwMDBa Fw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29y cG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlk dWFsIFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMbsJ/0dY/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7s A8snm48ggDfg5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7Y I09IUSNqYISo7icvYN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVp cLSp5Fbp2x1c9KY24mu1Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0 d/nAoccOcu9m4uW5yuDzhXc1mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJA MDgGCCsGAQUFBwEBBCwwKjAoBggrBgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWdu LmNvbTASBgNVHRMBAf8ECDAGAQH/AgEAMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAm BggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoa aHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2Ny bC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNVHQ4EFgQUrfnDk3IttbkoYeSk 12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYD VQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRp b24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IB AQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KW cFRwYk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aH maturZXBAD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt 1iqoyd7ZAAJP4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIHEzCCBfugAwIB AgIQQA2IH1dlro2ulxZcz+4MMjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAb BgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBO ZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFu dGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTQxMjE4MDAw MDAwWhcNMTUxMjE5MjM1OTU5WjCBzjEuMCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVk IC0gMTQxODg4MjEwMTAyMDErMCkGCSqGSIb3DQEJARYcamFsdG1hbkBzZWN1cmUtZW5kcG9p bnRzLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYDVQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHTAbBgNVBAoMFFN5bWFudGVj IENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxnG6iSpLXZAJ fuf957V+eQY5l/8a4s+wvFslpyNyHmih3Y+GGv1YUhn8QYufFKOFe8FflVwDmyvhJC4Dv7dj nbVDsM9OEl/GUacmcb8OWJS+dInkUbZO0isRny1W8SVdaXxp0QemjNczsbhE73bImHJU3KES VyqDB5VJqwvn+Ixdm8bug0D1aHeR6NpCXOVYjtZm508+y9n7kVph/Wn0K2vEOlGiVpyR69WU qpFqY2tGthseOwvOQmH3wKE19fro7mMINCwPAt0S9BZxr2pR+HWpbH04KbJIRBlykaTDAJYv Dqu2zjm9aMc4jPfskefr99L2d+2nQtr8fC9ZuBe1lwIDAQABo4IDETCCAw0wDAYDVR0TAQH/ BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTNie4wJCrT/MLp/t7Oa7+9uxA5HjAnBgNVHREEIDAegRxqYWx0bWFuQHNl Y3VyZS1lbmRwb2ludHMuY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIB KwYIKwYBBQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3Rvcnku dmVyaXNpZ24uY29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlk dWFsJTIwU3Vic2NyaWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25h JTIwTm90JTIwVmFsaWRhdGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIw TmV0d29yayUyQyUyME8lMjAlM0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUy MCUzRCUyMFVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6 Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4 MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUF BwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8v d3d3LnN5bWF1dGguY29tL3JwYTArBgpghkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGG x85vFgUxMDkyMjA5BgpghkgBhvhFARAFBCswKQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVj M2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUAA4IBAQC2axIcwU2XW8yc5xHsZFr2JiLt QNrPAfeajH5NPGk74Ptw+hesFBnmVSf+8fL608SEPb72L3214wwXaVi51aFGnhDNov/9esdt TR6nwBcOarUscuGEAE7kCKnr5PeitryCI4y/76yMGXr8DwT6ZP14QCODH7s6PPW7k/qSQfaR FRPCAjVD1XbsnXGQCdEdJvKkFSLChGKgJFCw9VOj/DipfGpW5RhZBbqlyEj23jJYODgPDOQV eSMRyBn1J14Thx/wC9cRPRlbeA5hnfMvesvpYyR1f5g/dzbyWh9OFuqLpw2/EQVbfA0b6tDC x7VmqVB5Rt8x/IvyCfKfY0OV3ckRMYIEYjCCBF4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0w GwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3Qg TmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1h bnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhBADYgfV2Wuja6X FlzP7gwyMA0GCWCGSAFlAwQCAQUAoIICdzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNTEyMTExNjUyMjJaMC8GCSqGSIb3DQEJBDEiBCBbuTkmmFKHfw/N uvjio4b7LbM8yfXPrv/ChKPg7SHRbDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHMBgkrBgEEAYI3EAQxgb4wgbswgaYxCzAJBgNV BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYD VQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhBA DYgfV2Wuja6XFlzP7gwyMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkGA1UEBhMCVVMx HTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVz dCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5 bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEEANiB9XZa6N rpcWXM/uDDIwDQYJKoZIhvcNAQEBBQAEggEAUAIWAlQMe4V0NpVXiht1BSlV2t3Xs+Vid66i O+ChVbQglAVuRl3gx6KXz7vfFLT8bOHHmLC+MWa6sBPbl7zhzYx4DWf0nd5Lr+UCXFR4g4GZ Gbau1ILA8ELomTVPQBN22iQoXdGCnf8uvfiMkrRPpNT9tRrT+iqyI4gYh86FSFoLHeKzJ985 13dP1LoQLsQ7VXgylO4Qh9Gnt95XGBkN3ZmwLFPEn6DIn2ZejoEtcv9hqayAmOUaqC3XacVb eHEVIdKi0NmQwU/8u0kEUgPsk2l8tNhbyzGdX6VdT/NReGAi+kaerPmIDIGOF2ueGxJqHwpz aFy2mRsAvmusVXdzaAAAAAAAAA== --------------ms010809020204050607040309-- From nobody Fri Dec 11 09:12:29 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569371B2A4D for ; Fri, 11 Dec 2015 09:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.012 X-Spam-Level: X-Spam-Status: No, score=-5.012 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfOTPMxoOTD1 for ; Fri, 11 Dec 2015 09:12:27 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E27E01A8746 for ; Fri, 11 Dec 2015 09:12:25 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 9CBFE4C518; Fri, 11 Dec 2015 17:12:25 +0000 (UTC) Received: from ovpn-113-187.phx2.redhat.com (ovpn-113-187.phx2.redhat.com [10.3.113.187]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tBBHCN7M011556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 11 Dec 2015 12:12:24 -0500 Message-ID: <1449853943.17418.103.camel@redhat.com> From: Simo Sorce To: Jeffrey Altman Date: Fri, 11 Dec 2015 12:12:23 -0500 In-Reply-To: <566AFF46.6080504@secure-endpoints.com> References: <20151209093754.GE3198@localhost> <566AFF46.6080504@secure-endpoints.com> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] New EncTypes? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 17:12:28 -0000 On Fri, 2015-12-11 at 11:52 -0500, Jeffrey Altman wrote: > On 12/10/2015 11:28 PM, Benjamin Kaduk wrote: > > > > You don't see potential in a chacha/poly scheme? Not that I'm > > volunteering to write the draft, mind you... > > I would like to see a chacha/poly enctype but I'm not going to fund its > development in the short term. > > It would be good to have a non-AES enctype in our back pocket even if we > aren't using it regularly today. MIT implements Camellia ... Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Fri Dec 11 09:36:39 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6341A1A8AD3 for ; Fri, 11 Dec 2015 09:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_FAEu4jNw_S for ; Fri, 11 Dec 2015 09:36:36 -0800 (PST) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.201.169]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB9211A883F for ; Fri, 11 Dec 2015 09:36:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id E03E7F601; Fri, 11 Dec 2015 12:36:35 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at mailout.easymail.ca Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfFSL79hhrag; Fri, 11 Dec 2015 12:36:35 -0500 (EST) Received: from [192.168.3.129] (71-80-163-186.static.lsan.ca.charter.com [71.80.163.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 2676AF479; Fri, 11 Dec 2015 12:36:35 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Henry B (Hank) Hotz, CISSP" In-Reply-To: <1449853943.17418.103.camel@redhat.com> Date: Fri, 11 Dec 2015 09:36:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151209093754.GE3198@localhost> <566AFF46.6080504@secure-endpoints.com> <1449853943.17418.103.camel@redhat.com> To: Simo Sorce X-Mailer: Apple Mail (2.2104) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] New EncTypes? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 17:36:38 -0000 IIUC Camillia is based on the same math as AES. I was advocating for = something unrelated. I think chacha/poly qualifies, so I=E2=80=99m = interested. > On Dec 11, 2015, at 9:12 AM, Simo Sorce wrote: >=20 > On Fri, 2015-12-11 at 11:52 -0500, Jeffrey Altman wrote: >> On 12/10/2015 11:28 PM, Benjamin Kaduk wrote: >>>=20 >>> You don't see potential in a chacha/poly scheme? Not that I'm >>> volunteering to write the draft, mind you... >>=20 >> I would like to see a chacha/poly enctype but I'm not going to fund = its >> development in the short term. >>=20 >> It would be good to have a non-AES enctype in our back pocket even if = we >> aren't using it regularly today. >=20 > MIT implements Camellia ... >=20 > Simo. >=20 > --=20 > Simo Sorce * Red Hat, Inc * New York >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten Personal: hbhotz@oxy.edu Business: hhotz@securechannels.com From nobody Fri Dec 11 12:20:01 2015 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B4B1A1AA1; Fri, 11 Dec 2015 12:19:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151211201958.791.87294.idtracker@ietfa.amsl.com> Date: Fri, 11 Dec 2015 12:19:58 -0800 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-rfc4402bis-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 20:19:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism Authors : Shawn Emery Nicolas Williams Filename : draft-ietf-kitten-rfc4402bis-02.txt Pages : 8 Date : 2015-12-11 Abstract: This document defines the Pseudo-Random Function (PRF) for the Kerberos V mechanism for the Generic Security Service Application Program Interface (GSS-API), based on the PRF defined for the Kerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context. This document obsoletes RFC 4402 and reclassifies that document as historic. RFC 4402 starts the PRF+ counter at 1, however a number of implementations starts the counter at 0. As a result, the original specification would not be interoperable with existing implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-rfc4402bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-kitten-rfc4402bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-rfc4402bis-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 11 14:18:26 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9820A1A909C for ; Fri, 11 Dec 2015 14:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.512 X-Spam-Level: X-Spam-Status: No, score=-0.512 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 393iYEHze2KQ for ; Fri, 11 Dec 2015 14:18:22 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 763C91A9096 for ; Fri, 11 Dec 2015 14:17:57 -0800 (PST) Received: by us.padl.com with ESMTP id tBBMHnXB009770; Fri, 11 Dec 2015 17:17:53 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luke Howard In-Reply-To: <566AFF46.6080504@secure-endpoints.com> Date: Sat, 12 Dec 2015 09:17:48 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <07899524-A5C8-4435-BF19-D7D8A4175739@padl.com> References: <20151209093754.GE3198@localhost> <566AFF46.6080504@secure-endpoints.com> To: Jeffrey Altman X-Mailer: Apple Mail (2.3096.5) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.9 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] New EncTypes? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 22:18:24 -0000 > On 12 Dec 2015, at 3:52 AM, Jeffrey Altman = wrote: >=20 > On 12/10/2015 11:28 PM, Benjamin Kaduk wrote: >>=20 >> You don't see potential in a chacha/poly scheme? Not that I'm >> volunteering to write the draft, mind you... >=20 > I would like to see a chacha/poly enctype but I'm not going to fund = its > development in the short term. >=20 > It would be good to have a non-AES enctype in our back pocket even if = we > aren't using it regularly today. I can=E2=80=99t promise an implementation, but RFC 7539 looks similar = enough to AES-GCM that I could profile it in the {krb,gss}-aead drafts = I=E2=80=99m writing. =E2=80=94 Luke= From nobody Fri Dec 11 14:21:27 2015 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FCE1A90C8; Fri, 11 Dec 2015 14:21:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151211222125.4545.47509.idtracker@ietfa.amsl.com> Date: Fri, 11 Dec 2015 14:21:25 -0800 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 22:21:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension Authors : Michiko Short Seth Moore Paul Miller Filename : draft-ietf-kitten-pkinit-freshness-02.txt Pages : 8 Date : 2015-12-11 Abstract: This document describes how to further extend the Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) extension [RFC4556] to exchange an opaque data blob that a KDC can validate to ensure that the client is currently in possession of the private key during a PKINIT AS exchange. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-pkinit-freshness/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-kitten-pkinit-freshness-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-pkinit-freshness-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 11 20:18:24 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1667F1ACEDF for ; Fri, 11 Dec 2015 20:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3KEdaQO5DWG for ; Fri, 11 Dec 2015 20:18:22 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11E561ACED5 for ; Fri, 11 Dec 2015 20:18:21 -0800 (PST) Received: by us.padl.com with ESMTP id tBC4ICWr021924; Fri, 11 Dec 2015 23:18:18 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luke Howard In-Reply-To: <20151211222125.4545.47509.idtracker@ietfa.amsl.com> Date: Sat, 12 Dec 2015 15:18:05 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <00976A8E-6EFA-4A4A-87DD-ED507B6945B4@padl.com> References: <20151211222125.4545.47509.idtracker@ietfa.amsl.com> To: "kitten@ietf.org" X-Mailer: Apple Mail (2.3096.5) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2015 04:18:23 -0000 In 5., there=E2=80=99s a missing space after the comma after Sam=E2=80=99= s second acknowledgement. =E2=80=94 Luke= From nobody Sat Dec 12 16:58:27 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045381A00CA for ; Sat, 12 Dec 2015 16:58:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJq03TDJ18T2 for ; Sat, 12 Dec 2015 16:58:24 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8791A00C3 for ; Sat, 12 Dec 2015 16:58:23 -0800 (PST) X-AuditID: 1209190c-f79c96d00000038e-9c-566cc2ae73a4 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id E1.05.00910.EA2CC665; Sat, 12 Dec 2015 19:58:22 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id tBD0wLXI009834 for ; Sat, 12 Dec 2015 19:58:22 -0500 Received: from [18.101.8.109] (vpn-18-101-8-109.mit.edu [18.101.8.109]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tBD0wJrA000955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sat, 12 Dec 2015 19:58:21 -0500 To: kitten@ietf.org References: <20151211222125.4545.47509.idtracker@ietfa.amsl.com> From: Greg Hudson X-Enigmail-Draft-Status: N1110 Message-ID: <566CC2AB.2060906@mit.edu> Date: Sat, 12 Dec 2015 19:58:19 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151211222125.4545.47509.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixG6norvuUE6YwauDShZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxp3lTUwF86QqHu8WbmBcJ9rFyMEhIWAisfx8SBcjJ5ApJnHh 3nq2LkYuDiGBxUwSn44/YIdwjjNKfHh5Fypzi0niw6P57CAtwgLeEr/XL2cEsUUEhCV2b33H DGILCThIbL7yHayGTUBZYv3+rSwQK+Qkersngdm8AmoSb1a/BqthEVCVmNbZyQxykahAhMSi HZkQJYISJ2c+ASvnFHCUmDP9BhOIzSygJ7Hj+i9WCFteonnrbOYJjIKzkLTMQlI2C0nZAkbm VYyyKblVurmJmTnFqcm6xcmJeXmpRbqGermZJXqpKaWbGEGByinJs4PxzUGlQ4wCHIxKPLwn mnPChFgTy4orcw8xSnIwKYnyLu/ODhPiS8pPqcxILM6ILyrNSS0+xCjBwawkwru/DaicNyWx siq1KB8mJc3BoiTOO/eLb5iQQHpiSWp2ampBahFMVoaDQ0mCt+cgUKNgUWp6akVaZk4JQpqJ gxNkOA/Q8D0gNbzFBYm5xZnpEPlTjIpS4rxhIAkBkERGaR5cLziRpHLkvmIUB3pFmDcApIoH mITgul8BDWYCGnz0ZDbI4JJEhJRUA2PKB5WzVXpXVNqPTdcTPXjy2reN2rldkzQTnH7+ml/2 8dSK766SV1f/fZ43+V5kgmCj739HofeOItIP3i3RWsv4XST4/vvU7vvcNnadi7ozwoOl/BOq ZFQXLdjCJM3PbLelqipx7+WL0iG3pFYvzWd/K/nGo2f+DiOvxHjjdW4FIkwS7CG7u5VYijMS DbWYi4oTAfB0zxb/AgAA Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2015 00:58:26 -0000 I have just one substantive concern: If the freshness token is not valid, the KDC MUST return KDC_ERR_PREAUTH_EXPIRED [RFC6113] with PA_AS_FRESHNESS. [...] If a client receives a KDC_ERR_PREAUTH_EXPIRED KRB_ERROR message that includes a freshness token, [...] KDC_ERR_PREAUTH_FAILED has been changed to KDC_ERR_PREAUTH_EXPIRED as I requested. However, it still talks vaguely about including a freshness token in the error, which I noted as a problem in my August 17 feedback. In RFC 4120, the e-data field is an octet string whose form and semantics depend on the error code, with speculation that it might contain TYPED-DATA (a presumption which we have since abandoned). Only KDC_ERR_PREAUTH_REQUIRED has a specified e-data format in RFC 4120; that format is METHOD-DATA, which is a SEQUENCE OF PA-DATA. RFC 6113 section 5.4.4 implicitly forces all error e-data to be in METHOD-DATA form if the error might occur in response to a FAST request. A facility is given for translating TYPED-DATA to METHOD-DATA, but there unfortunately isn't an explicit statement about how the e-data model is changed. Sam alluded to this in March 2009: http://www.ietf.org/mail-archive/web/krb-wg/current/msg00067.html An implementor who sees "KDC_ERR_PREAUTH_EXPIRED with PA_AS_FRESHNESS" might do several things, depending on their depth of understanding. With a good understanding of RFC 6113 (or perhaps by accident), they might encode METHOD-DATA containing a PA_AS_FRESHNESS element and put that in the e-data field. With a bad understanding, the implementor might put the freshness value directly in the e-data field, or something else. In my August 17 feedback, I suggested: > One alternative is to use KDC_ERR_PREAUTH_EXPIRED from RFC 6113. There > is no specification for including METHOD-DATA in such an error, so the > client would have to restart from scratch, without the benefit of a > newly valid freshness token. But I think that is okay; recovering from > a delay which resulted in a not-so-fresh freshness token should not be a > common scenario. I still think that is the simplest thing to do. There is no need to optimize round-trips for such an uncommon scenario. At a minimum, I think clients should be allowed to respond to KDC_ERR_PREAUTH_EXPIRED by restarting with an unauthenticated AS-REQ. Editorial concerns: * "Public key encryption requires certificates with an encryption key, that is not deployed on many existing smart cards": he added comma is good, but "which" should not have been changed to "that," as the clause is non-restrictive. (Ben's August 16 feedback was not meant to apply to every use of the word "which".) * "the client uses its private key only to sign the AuthPack structure (...), that is performed before any traffic is sent to the KDC": again, "which" should not have been changed to "that," as the clause is non-restrictive. * Section 2.3, "The PA_AS_FRESHNESS padata-value field of the PA-DATA structure SHALL": strike the "PA_AS_FRESHNESS" from this sentence. (This was a problem with the previous version of the draft, which I failed to notice in my August 17 feedback.) * Section 7: "single use" should be "single-use". * Section 8: add a comma before the word "depending." Add a "the" before "existing". From nobody Sat Dec 12 17:49:18 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FCE1A1AB3 for ; Sat, 12 Dec 2015 17:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.788 X-Spam-Level: X-Spam-Status: No, score=0.788 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5eieASMgknC for ; Sat, 12 Dec 2015 17:49:15 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D9841A1A7D for ; Sat, 12 Dec 2015 17:49:15 -0800 (PST) Received: by us.padl.com with ESMTP id tBD1n9d5001679; Sat, 12 Dec 2015 20:49:12 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luke Howard In-Reply-To: <566AFF46.6080504@secure-endpoints.com> Date: Sun, 13 Dec 2015 12:49:07 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <0558AED9-8BC3-47E1-B9E6-77F154A9DC47@padl.com> References: <20151209093754.GE3198@localhost> <566AFF46.6080504@secure-endpoints.com> To: Jeffrey Altman X-Mailer: Apple Mail (2.3096.5) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.8 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] New EncTypes? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2015 01:49:17 -0000 > On 12 Dec 2015, at 3:52 AM, Jeffrey Altman = wrote: >=20 > On 12/10/2015 11:28 PM, Benjamin Kaduk wrote: >>=20 >> You don't see potential in a chacha/poly scheme? Not that I'm >> volunteering to write the draft, mind you... >=20 > I would like to see a chacha/poly enctype but I'm not going to fund = its > development in the short term. As soon as OpenSSL 1.1.0 is released and supported by Heimdal, an = implementation of chacha20-poly1305 will be trivial in the aes-gcm = branch. =E2=80=94 Luke= From nobody Sun Dec 13 00:25:15 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DBC1AC40B for ; Sun, 13 Dec 2015 00:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9A6OrjHcraz for ; Sun, 13 Dec 2015 00:25:12 -0800 (PST) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0A2A1AC408 for ; Sun, 13 Dec 2015 00:25:11 -0800 (PST) Received: from airhead.local ([83.161.146.46]) by smtp-cloud6.xs4all.net with ESMTP id swR71r00410HQrX01wR8dD; Sun, 13 Dec 2015 09:25:09 +0100 Message-ID: <566D2B64.5030609@openfortress.nl> Date: Sun, 13 Dec 2015 09:25:08 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "Henry B (Hank) Hotz, CISSP" References: <20151209093754.GE3198@localhost> <566AFF46.6080504@secure-endpoints.com> <1449853943.17418.103.camel@redhat.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: kitten@ietf.org, Simo Sorce Subject: Re: [kitten] New EncTypes? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2015 08:25:14 -0000 Hi > IIUC Camillia is based on the same math as AES. I was advocating for > something unrelated. I think chacha/poly qualifies, so I’m interested. > That is actually a very good idea. Such a good idea, that one wonders why only one of the AES contestors was standardised. Could any of the alternatives to Rijndael be worth a further look? This effort would probably be beneficial for protocols other than Kerberos. -Rick From nobody Sun Dec 13 00:47:07 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F45B1ACD04 for ; Sun, 13 Dec 2015 00:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkzmfKVsh_Py for ; Sun, 13 Dec 2015 00:47:05 -0800 (PST) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A10B71ACD03 for ; Sun, 13 Dec 2015 00:47:04 -0800 (PST) Received: from airhead.local ([83.161.146.46]) by smtp-cloud6.xs4all.net with ESMTP id swn11r00J10HQrX01wn2C0; Sun, 13 Dec 2015 09:47:02 +0100 Message-ID: <566D3084.2020405@openfortress.nl> Date: Sun, 13 Dec 2015 09:47:00 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: kitten@ietf.org References: <20151209093754.GE3198@localhost> <566AFF46.6080504@secure-endpoints.com> <1449853943.17418.103.camel@redhat.com> <566D2B64.5030609@openfortress.nl> <566D3061.6090208@openfortress.nl> In-Reply-To: <566D3061.6090208@openfortress.nl> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [kitten] New EncTypes? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2015 08:47:06 -0000 Hi, > one wonders > why only one of the AES contestors was standardised. Following up on this thought, I selected some trivia from WikiPedia: All five algorithms, commonly referred to as "AES finalists", were designed by cryptographers considered well-known and respected in the community. The AES2 conference votes were as follows: * Rijndael: 86 positive, 10 negative * Serpent: 59 positive, 7 negative * Twofish: 31 positive, 21 negative * RC6: 23 positive, 37 negative * MARS: 13 positive, 84 negative All have the same interface as AES, a block size of 128 bits and support for a key size of 128, 192 or 256 bits. The official NIST report on AES competition classified Serpent as having a high security margin along with MARS and Twofish, in contrast to the adequate security margin of RC6 and Rijndael (currently AES).[3] In final voting, Serpent had the least number of negative votes among the finalists, but scored second place overall because Rijndael had substantially more positive votes, the deciding factor being that Rijndael allowed for a far more efficient software implementation. [3] Report on the Development of the Advanced Encryption Standard (AES) http://csrc.nist.gov/archive/aes/round2/r2report.pdf Sources: https://en.wikipedia.org/wiki/Advanced_Encryption_Standard_process https://en.wikipedia.org/wiki/Serpent_(cipher) Cheers, -Rick From nobody Sun Dec 13 03:48:44 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAC11A21A6 for ; Sun, 13 Dec 2015 03:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajxXZWb9ch0n for ; Sun, 13 Dec 2015 03:48:41 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C2121A21A5 for ; Sun, 13 Dec 2015 03:48:41 -0800 (PST) Received: by us.padl.com with ESMTP id tBDBmWWC024466; Sun, 13 Dec 2015 06:48:37 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luke Howard In-Reply-To: <566D3084.2020405@openfortress.nl> Date: Sun, 13 Dec 2015 22:48:31 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <6BC24542-9AA9-4B65-B729-809E67CE878E@padl.com> References: <20151209093754.GE3198@localhost> <566AFF46.6080504@secure-endpoints.com> <1449853943.17418.103.camel@redhat.com> <566D2B64.5030609@openfortress.nl> <566D3061.6090208@openfortress.nl> <566D3084.2020405@openfortress.nl> To: "kitten@ietf.org" X-Mailer: Apple Mail (2.3096.5) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.8 Archived-At: Subject: Re: [kitten] New EncTypes? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2015 11:48:42 -0000 As a historical note, the early RFC3961 drafts did specify Serpent and = Twofish as well as AES: https://tools.ietf.org/html/draft-raeburn-krb-rijndael-krb-01 =E2=80=94 Luke= From nobody Sun Dec 13 17:33:13 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36EBD1A87EF for ; Sun, 13 Dec 2015 17:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luqN_NQQAKsZ for ; Sun, 13 Dec 2015 17:33:10 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 437631A87BD for ; Sun, 13 Dec 2015 17:33:10 -0800 (PST) Received: by us.padl.com with ESMTP id tBE1X4XR007926; Sun, 13 Dec 2015 20:33:07 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luke Howard In-Reply-To: <7216FCF9-6F37-4D23-8A36-F75E7ED4EB7C@padl.com> Date: Mon, 14 Dec 2015 12:33:02 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> <1D0FEA3E-A8D7-4702-B228-FAF697BB427A@padl.com> <5666640C.2050401@mit.edu> <20151208223656.GD23318@localhost> <7216FCF9-6F37-4D23-8A36-F75E7ED4EB7C@padl.com> To: "kitten@ietf.org" X-Mailer: Apple Mail (2.3096.5) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.8 Archived-At: Subject: [kitten] RFC 3961 AEAD extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 01:33:12 -0000 This document defines extensions to RFC 3961 for use with AEAD ciphers = that require deterministic initialisation vectors (such as GCM), by = allowing encryption types to modify their behaviour depending on whether = they are being used with long-term keys or not. https://www.ietf.org/id/draft-howard-krb-aead-00.txt =E2=80=94 Luke= From nobody Sun Dec 13 17:46:49 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15041A9034 for ; Sun, 13 Dec 2015 17:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bO55VvdQGS8D for ; Sun, 13 Dec 2015 17:46:46 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFED11A903E for ; Sun, 13 Dec 2015 17:46:27 -0800 (PST) Received: by us.padl.com with ESMTP id tBE1kJRx009439; Sun, 13 Dec 2015 20:46:25 -0500 From: Luke Howard Content-Type: multipart/alternative; boundary="Apple-Mail=_7C3C1E3A-3CDF-4AA7-8A72-FD806ED3F161" Message-Id: <13DFE945-A1A9-4845-9C76-B3DFB89BB5D4@padl.com> Date: Mon, 14 Dec 2015 12:46:18 +1100 To: "kitten@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,HTML_MESSAGE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.8 Archived-At: Subject: [kitten] RFC 4121 AEAD extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 01:46:48 -0000 --Apple-Mail=_7C3C1E3A-3CDF-4AA7-8A72-FD806ED3F161 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This document defines extensions to RFC 4121 for using the AEAD = encryption types defined in draft-howard-krb-aead. https://www.ietf.org/id/draft-howard-gssapi-aead-00.txt = =E2=80=94 Luke -- www.lukehoward.com soundcloud.com/lukehoward --Apple-Mail=_7C3C1E3A-3CDF-4AA7-8A72-FD806ED3F161 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This document defines extensions to RFC 4121 for using the = AEAD encryption types defined in draft-howard-krb-aead.

https://www.ietf.org/id/draft-howard-gssapi-aead-00.txt

=E2=80=94 Luke
--
www.lukehoward.com
soundcloud.com/lukehoward

= --Apple-Mail=_7C3C1E3A-3CDF-4AA7-8A72-FD806ED3F161-- From nobody Sun Dec 13 18:13:08 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC41B1A9092 for ; Sun, 13 Dec 2015 18:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgrTtQxy55CO for ; Sun, 13 Dec 2015 18:13:06 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E195F1A9091 for ; Sun, 13 Dec 2015 18:13:05 -0800 (PST) Received: by us.padl.com with ESMTP id tBE2Cx6O010142; Sun, 13 Dec 2015 21:13:02 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luke Howard In-Reply-To: <5666640C.2050401@mit.edu> Date: Mon, 14 Dec 2015 13:12:57 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> <1D0FEA3E-A8D7-4702-B228-FAF697BB427A@padl.com> <5666640C.2050401@mit.edu> To: Greg Hudson X-Mailer: Apple Mail (2.3096.5) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.8 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] AES-GCM for Kerberos GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 02:13:07 -0000 > On 8 Dec 2015, at 4:01 PM, Greg Hudson wrote: >=20 > On 12/07/2015 07:28 PM, Luke Howard wrote: >> Nico doesn=92t think this is worth worrying about (GCM spec says that = it=92s >> OK to have a completely deterministic IV as long as it=92s not reused = with >> the same key), but perhaps the extra entropy / consistency with >> TLS/IPsec is a good idea? >=20 > I agree with Nico; I think this is extra complexity we don't want or = need. Reading RFC 3610 Section 5, this would help guard against = pre-computation attacks, but so does the choice of a random initial = sequence number in the AP-REQ (RFC 1510 section 3.2.2). Anyway, on your advice I did not pursue this approach. =97 Luke From nobody Sun Dec 13 20:08:31 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB6861A89AF for ; Sun, 13 Dec 2015 20:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXM8gh9ZpSh5 for ; Sun, 13 Dec 2015 20:08:29 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5776C1A8848 for ; Sun, 13 Dec 2015 20:08:29 -0800 (PST) X-AuditID: 12074422-f79c46d000006aa7-f8-566e40bce541 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 86.CF.27303.CB04E665; Sun, 13 Dec 2015 23:08:28 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id tBE48SUE011194; Sun, 13 Dec 2015 23:08:28 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tBE48O85026899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 13 Dec 2015 23:08:27 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id tBE48Ojf018025; Sun, 13 Dec 2015 23:08:24 -0500 (EST) Date: Sun, 13 Dec 2015 23:08:24 -0500 (EST) From: Benjamin Kaduk To: Rick van Rein In-Reply-To: <566D2B64.5030609@openfortress.nl> Message-ID: References: <20151209093754.GE3198@localhost> <566AFF46.6080504@secure-endpoints.com> <1449853943.17418.103.camel@redhat.com> <566D2B64.5030609@openfortress.nl> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1369982221-1450066104=:26829" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IRYrdT193jkBdmcPWtscXRzatYLJ6+usfm wOSxZMlPJo8N/5rYApiiuGxSUnMyy1KL9O0SuDJuzZ/LWjCNs+L9g4uMDYy72LsYOTkkBEwk vs3+ywJhi0lcuLeerYuRi0NIYDGTxKPj/ewQzkZGiW3N65ggnENMEvfm/mUEaRESaGCUOHib C8RmEdCW+PhkEtgoNgEViZlvNrKB2CICGhKff00Fs5kFhCXWn5vB3MXIwSEsoCzx4psSSJhT QF/ixcOLYGFeAUeJxadVIFZtY5JYt3Q/2EhRAR2J1fungNm8AoISJ2c+YYEYGShx8m4z0wRG wVlIUrOQpCBsPYlX/+YzQtjaEvdvtrEtYGRZxSibklulm5uYmVOcmqxbnJyYl5dapGuql5tZ opeaUrqJERzYLko7GH8eVDrEKMDBqMTDm7EsN0yINbGsuDL3EKMkB5OSKO/y7uwwIb6k/JTK jMTijPii0pzU4kOMEhzMSiK8CVZ5YUK8KYmVValF+TApaQ4WJXHeuV98w4QE0hNLUrNTUwtS i2CyMhwcShK8KfZAjYJFqempFWmZOSUIaSYOTpDhPEDDq0BqeIsLEnOLM9Mh8qcYFaXEeSNB EgIgiYzSPLhecOLZzaT6ilEc6BVhXguQKh5g0oLrfgU0mAlo8NGT2SCDSxIRUlINjHZtDW9L G1tiEuwZ/S76m/y/9GFWg7y6baPN3Yk2RTJ36uc/VRRrNdleI3QnVn2h0obpa24fyDy0WVKr csWKULuWvbqlNpHPBDP+mtoc0SgNmnT6zpe/Bxc5pqwv7/9yaU/A1slspxaenp+91GJGmtH5 6EOC9xm/vlgQtktNvd3t3ntJ/zU6RUosxRmJhlrMRcWJAII0+osXAwAA Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] New EncTypes? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 04:08:31 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1369982221-1450066104=:26829 Content-Type: TEXT/PLAIN; charset=windows-1252 Content-Transfer-Encoding: QUOTED-PRINTABLE On Sun, 13 Dec 2015, Rick van Rein wrote: > Hi > > > IIUC Camillia is based on the same math as AES. I was advocating for > > something unrelated. I think chacha/poly qualifies, so I=92m interested= =2E > > > That is actually a very good idea. Such a good idea, that one wonders > why only one of the AES contestors was standardised. Could any of the > alternatives to Rijndael be worth a further look? This effort would > probably be beneficial for protocols other than Kerberos. Perhaps, but one should probably assume that people working on other protocols are clever enough to have the same idea and have discarded it for one reason or another. If there is a need for it in Kerberos, by all means go ahead, but I do not think we are necessarily the leaders of crypto primitive usage in software, anymore. -Ben ---559023410-1369982221-1450066104=:26829-- From nobody Sun Dec 13 21:34:51 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5640F1ACCF8 for ; Sun, 13 Dec 2015 21:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9L3NuR54odFI for ; Sun, 13 Dec 2015 21:34:48 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECDF11AC3F8 for ; Sun, 13 Dec 2015 21:34:47 -0800 (PST) X-AuditID: 12074424-f79216d00000156e-bf-566e54f6aad5 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 93.4D.05486.6F45E665; Mon, 14 Dec 2015 00:34:46 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id tBE5Yj84004887; Mon, 14 Dec 2015 00:34:46 -0500 Received: from [18.101.8.84] (vpn-18-101-8-84.mit.edu [18.101.8.84]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tBE5Yh2d015969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Dec 2015 00:34:45 -0500 To: Luke Howard , "kitten@ietf.org" References: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> <1D0FEA3E-A8D7-4702-B228-FAF697BB427A@padl.com> <5666640C.2050401@mit.edu> <20151208223656.GD23318@localhost> <7216FCF9-6F37-4D23-8A36-F75E7ED4EB7C@padl.com> From: Greg Hudson X-Enigmail-Draft-Status: N1110 Message-ID: <566E54F3.9030308@mit.edu> Date: Mon, 14 Dec 2015 00:34:43 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixG6novstJC/MoH+TnsXRzatYLO5e+s/u wOSxZMlPJo+5H6axBDBFcdmkpOZklqUW6dslcGXcXraOveAAZ8W6Y3+YGhjvsXcxcnJICJhI zFj5kwnCFpO4cG89WxcjF4eQwGImiW+Pt7JAOBsZJXatnwmVOcgkcfTwNrB2YQE9icYp+xlB bBEBV4nZy5ZBFR1mkuju3cYCkmATUJZYv38rC8QOOYne7klgNq+AmsTrluNAgzg4WARUJXY+ MAMxRQUiJBbtyISoEJQ4OfMJWDWngI3E6g8/wVYxC6hL/Jl3iRnClpdo3jqbeQKj4CwkLbOQ lM1CUraAkXkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrrlebmaJXmpK6SZGcAC7qOxgbD6kdIhR gINRiYc3Y1lumBBrYllxZe4hRkkOJiVR3uXd2WFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHgT rPLChHhTEiurUovyYVLSHCxK4rxzv/iGCQmkJ5akZqemFqQWwWRlODiUJHivBwM1ChalpqdW pGXmlCCkmTg4QYbzAA0vBqnhLS5IzC3OTIfIn2JUlBLnDQdJCIAkMkrz4HrBCSaVI+QVozjQ K8K8JSBVPMDkBNf9CmgwE9DgoyezQQaXJCKkpBoYnXh6j8gaJ0T1ObW/sFJ69jfTydmp8tP0 DW13ijVW/Gfvu9UstPHf36fuJWk373hkvV5ooOr/N8PlftDDfxsLFZR0bj3Qck6XPzePTcmL 98KzaTl9b+8K/Dh289wqhvkXXQ3utFybZrZxz9W3R1+ys8TdspRekLKpIMWg9c5hbeurWSwX Cw7vUmIpzkg01GIuKk4EAFxdmkgLAwAA Archived-At: Subject: Re: [kitten] RFC 3961 AEAD extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 05:34:49 -0000 On 12/13/2015 08:33 PM, Luke Howard wrote: > This document defines extensions to RFC 3961 for use with AEAD ciphers that require deterministic initialisation vectors (such as GCM), by allowing encryption types to modify their behaviour depending on whether they are being used with long-term keys or not. I am tentatively okay with reserving points in the enctype namespace for use with GSS AEAD enctypes (I'll call them that even though they could be used by other protocols), so that we can use RFC 4537 enctype negotiation during the AP-REQ/AP-REP exchange to negotiate their use. I am tentatively opposed to sharing any part of the abstract API between RFC 3961 ciphers and these GSS AEAD enctypes. There's too much potential for misuse. I think we can avoid having to define a KDF (and therefore bring in dependencies on additional primitives, such as SHA-256 for chacha20-poly1305). We may not need an analog to "key usage numbers" at all, as these enctypes are only for use with ephemeral keys, never with the same key across multiple protocols. If we do determine a need for key usage numbers, I think they could be included at the beginning of the additional data for each message. From nobody Sun Dec 13 21:53:53 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699F71ACDB7 for ; Sun, 13 Dec 2015 21:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptmwB-1V3AK2 for ; Sun, 13 Dec 2015 21:53:49 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C70CE1ACD80 for ; Sun, 13 Dec 2015 21:53:49 -0800 (PST) Received: by us.padl.com with ESMTP id tBE5rdew017616; Mon, 14 Dec 2015 00:53:42 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luke Howard In-Reply-To: <566E54F3.9030308@mit.edu> Date: Mon, 14 Dec 2015 16:53:37 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <719F56B0-BA00-40BA-8902-41F08B03E3FC@padl.com> References: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> <1D0FEA3E-A8D7-4702-B228-FAF697BB427A@padl.com> <5666640C.2050401@mit.edu> <20151208223656.GD23318@localhost> <7216FCF9-6F37-4D23-8A36-F75E7ED4EB7C@padl.com> <566E54F3.9030308@mit.edu> To: Greg Hudson X-Mailer: Apple Mail (2.3096.5) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.9 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] RFC 3961 AEAD extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 05:53:51 -0000 Hi Greg, Thanks for the quick feedback. > I am tentatively opposed to sharing any part of the abstract API = between > RFC 3961 ciphers and these GSS AEAD enctypes. There's too much > potential for misuse. Right, this is the alternate approach: define a single update to RFC = 4121 for use with AEAD encryption types, where RFC 3961 is imported = purely in order to leverage RFC 4537 enctype negotiation. =46rom an = implementation perspective: for Heimdal, it was ostensibly easier to = implement this at the RFC 3961 layer. I agree it is probably impossible = to completely guard against misuse. For the record I did the following = to mitigate against misuse in my Heimdal implementation: * No string-to-key function or associated checksum types will make most = non-AEAD usages fail * IV must be non-NULL on call to encrypt/decrypt * AEAD encryption types unavailable except through krb5_encrypt_iov_ivec = API * Encryption type enumerate APIs hide any AEAD types unless the consumer = is RFC 4537 Jeff: would be good to hear your thoughts on how useful GCM/etc are for = non-GSS-API use (e.g. OpenAFS). > I think we can avoid having to define a KDF (and therefore bring in > dependencies on additional primitives, such as SHA-256 for > chacha20-poly1305). We may not need an analog to "key usage numbers" = at > all, as these enctypes are only for use with ephemeral keys, never = with > the same key across multiple protocols. If we do determine a need for > key usage numbers, I think they could be included at the beginning of > the additional data for each message. Good point. Yes, if this is really a RFC 4121 only profile, then TOK_ID = is sufficient to disambiguate the Wrap and MIC usages, and we do not = need any key derivation. =E2=80=94 Luke= From nobody Sun Dec 13 22:07:29 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D821B2C68 for ; Sun, 13 Dec 2015 22:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8gFfVofkPjI for ; Sun, 13 Dec 2015 22:07:24 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 562921B2C11 for ; Sun, 13 Dec 2015 22:07:24 -0800 (PST) Received: by us.padl.com with ESMTP id tBE67Avh017854; Mon, 14 Dec 2015 01:07:21 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luke Howard In-Reply-To: <566E54F3.9030308@mit.edu> Date: Mon, 14 Dec 2015 17:07:09 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> <1D0FEA3E-A8D7-4702-B228-FAF697BB427A@padl.com> <5666640C.2050401@mit.edu> <20151208223656.GD23318@localhost> <7216FCF9-6F37-4D23-8A36-F75E7ED4EB7C@padl.com> <566E54F3.9030308@mit.edu> To: Greg Hudson X-Mailer: Apple Mail (2.3096.5) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.9 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] RFC 3961 AEAD extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 06:07:29 -0000 Another approach is that we do actually define an approach for long-term = keys (although I=E2=80=99m not sure how we=E2=80=99d do this elegantly = with existing Unix APIs =E2=80=93 perhaps checking for the absence of a = HEADER in the IOV APIs). KDF for long-term keys could be KDF(base-key, confounder | usage | = 0xAA). I=E2=80=99m sure there are other workable constructions. But =E2=80=93 this is all additional complexity for implementations to = deal with. =E2=80=94 Luke= From nobody Sun Dec 13 22:14:16 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F671B2C82 for ; Sun, 13 Dec 2015 22:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrsExPm63ZtP for ; Sun, 13 Dec 2015 22:14:14 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 408651B2C80 for ; Sun, 13 Dec 2015 22:14:14 -0800 (PST) Received: by us.padl.com with ESMTP id tBE6E9ZA017957; Mon, 14 Dec 2015 01:14:12 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luke Howard In-Reply-To: <566E54F3.9030308@mit.edu> Date: Mon, 14 Dec 2015 17:14:08 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> <1D0FEA3E-A8D7-4702-B228-FAF697BB427A@padl.com> <5666640C.2050401@mit.edu> <20151208223656.GD23318@localhost> <7216FCF9-6F37-4D23-8A36-F75E7ED4EB7C@padl.com> <566E54F3.9030308@mit.edu> To: Greg Hudson X-Mailer: Apple Mail (2.3096.5) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.9 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] RFC 3961 AEAD extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 06:14:15 -0000 > On 14 Dec 2015, at 4:34 PM, Greg Hudson wrote: >=20 > I am tentatively opposed to sharing any part of the abstract API = between > RFC 3961 ciphers and these GSS AEAD enctypes. There's too much > potential for misuse. As a middle ground, we could stay a little clearer of RFC 3961 but still = define the AEAD primitives separately so that non-GSS consumers can = still take advantage of them. =E2=80=94 Luke= From nobody Mon Dec 14 09:55:07 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C3B1AD0CC for ; Mon, 14 Dec 2015 09:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-QARHEEQyCF for ; Mon, 14 Dec 2015 09:54:58 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 472F71AD0CD for ; Mon, 14 Dec 2015 09:54:56 -0800 (PST) X-AuditID: 12074425-f793c6d000006975-b2-566f026fa6f0 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 96.FA.26997.F620F665; Mon, 14 Dec 2015 12:54:55 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id tBEHssIJ013125; Mon, 14 Dec 2015 12:54:55 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tBEHspjZ022789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Dec 2015 12:54:53 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id tBEHsoG1002433; Mon, 14 Dec 2015 12:54:50 -0500 (EST) Date: Mon, 14 Dec 2015 12:54:50 -0500 (EST) From: Benjamin Kaduk To: Luke Howard In-Reply-To: <719F56B0-BA00-40BA-8902-41F08B03E3FC@padl.com> Message-ID: References: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> <1D0FEA3E-A8D7-4702-B228-FAF697BB427A@padl.com> <5666640C.2050401@mit.edu> <20151208223656.GD23318@localhost> <7216FCF9-6F37-4D23-8A36-F75E7ED4EB7C@padl.com> <566E54F3.9030308@mit.edu> <719F56B0-BA00-40BA-8902-41F08B03E3FC@padl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrJvPlB9m0HdBx+Lo5lUsFncv/Wd3 YPJYsuQnk8fcD9NYApiiuGxSUnMyy1KL9O0SuDK+nFvPXHCap+JS8xO2BsY1XF2MnBwSAiYS p/7/YoewxSQu3FvP1sXIxSEksJhJYs3Eb1DORkaJ6QdbmSCcQ0wSix79YIRwGhglNk55xgzS zyKgLfHu/RxWEJtNQEVi5puNbCC2iICCxOT9a4FqODiYBdwk/v7iBgkLC+hJNE7ZzwgS5hSw kZjRqwIS5hVwlLgz7wELxPg2ZolFu46AjRQV0JFYvX8KC0SRoMTJmU/AbGYBLYnl07exTGAU nIUkNQtJagEj0ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdC73czBK91JTSTYygUGV3Ud3BOOGQ 0iFGAQ5GJR7ejGW5YUKsiWXFlbmHGCU5mJREec2+54UJ8SXlp1RmJBZnxBeV5qQWH2KU4GBW EuG1Y8gPE+JNSaysSi3Kh0lJc7AoifPO/eIbJiSQnliSmp2aWpBaBJOV4eBQkuANZgRqFCxK TU+tSMvMKUFIM3FwggznARrOCFLDW1yQmFucmQ6RP8WoKCXOGwGSEABJZJTmwfWCU8luJtVX jOJArwjzrgCp4gGmIbjuV0CDmYAGHz2ZDTK4JBEhJdXAeFyvVozHOEj12Fa7108/Pn8R13P4 3DqZszGvJtesX9/3bmZaxdbf/L/ex09t/ZYk+edF90s2s9trref/bNk94db19n/5HFH3Kn1V o5boC3sc8l+w8LGB0LaN61iS7HkvqSYrPjCulap4NfPi/L8X5pz/Xdkc8OhsaLqc6aJVhfK5 Lw1l7eduzVZiKc5INNRiLipOBADYCIEtAAMAAA== Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] RFC 3961 AEAD extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 17:55:01 -0000 On Mon, 14 Dec 2015, Luke Howard wrote: > > * No string-to-key function or associated checksum types will make most non-AEAD usages fail > * IV must be non-NULL on call to encrypt/decrypt > * AEAD encryption types unavailable except through krb5_encrypt_iov_ivec API > * Encryption type enumerate APIs hide any AEAD types unless the consumer is RFC 4537 > > Jeff: would be good to hear your thoughts on how useful GCM/etc are for > non-GSS-API use (e.g. OpenAFS). I'm not Jeff, but I am a coauthor on the rxgk-afs specs [0,1] that would be applicable for OpenAFS. We only use GSS-API for a single negotiation loop in which the AFS server essentually functions as a kerberos KDC, vending a ticket-analogue ("token") that is used to authenticate subsequent connections. The "session key" contained in that token (called the "token master key") is not used directly; instead a unique transport key is generated for each connection using PRF+ (this is section 8.3 of [0]). It is these subsequent connections that perform bulk data transfer, and one would expect that GCM/etc would provide some speed benefit, to the extent that the network stack is not the bottleneck. (The OpenAFS rx stack is notoriously non-performant, particularly for links with large RTT.) But, the network can be improved with "just" a "small matter of programming", so it seems beneficial to provide a way that these new enctypes could be used by non-GSSAPI protocols. -Ben [0] https://tools.ietf.org/html/draft-wilkinson-afs3-rxgk-11 [1] https://tools.ietf.org/html/draft-wilkinson-afs3-rxgk-afs-08 From nobody Mon Dec 14 10:20:18 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6B41B2AA6 for ; Mon, 14 Dec 2015 10:20:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRUqpNY96BZH for ; Mon, 14 Dec 2015 10:20:15 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1610B1A9252 for ; Mon, 14 Dec 2015 10:20:14 -0800 (PST) X-AuditID: 12074424-f79216d00000156e-54-566f085d853c Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 78.E0.05486.D580F665; Mon, 14 Dec 2015 13:20:13 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id tBEIKCZA011006; Mon, 14 Dec 2015 13:20:13 -0500 Received: from [18.101.8.145] (vpn-18-101-8-145.mit.edu [18.101.8.145]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tBEIKArj008323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Dec 2015 13:20:12 -0500 To: Benjamin Kaduk , Luke Howard References: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> <1D0FEA3E-A8D7-4702-B228-FAF697BB427A@padl.com> <5666640C.2050401@mit.edu> <20151208223656.GD23318@localhost> <7216FCF9-6F37-4D23-8A36-F75E7ED4EB7C@padl.com> <566E54F3.9030308@mit.edu> <719F56B0-BA00-40BA-8902-41F08B03E3FC@padl.com> From: Greg Hudson X-Enigmail-Draft-Status: N1110 Message-ID: <566F085A.1050503@mit.edu> Date: Mon, 14 Dec 2015 13:20:10 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsUixCmqrRvLkR9mcOqBqcXRzatYLO5e+s/u wOSxZMlPJo+5H6axBDBFcdmkpOZklqUW6dslcGU82vCVseAMS8X6pptsDYw3mbsYOTkkBEwk 2h/MgbLFJC7cW8/WxcjFISSwmEliyZVtzBDORkaJFZ07mSCcI0wS677tYwVpERbQk2icsp8R xBYRcJA4s/kkC0TRCWaJiWs+s4EkmAXUJY4+bwKz2QSUJdbv38oCsU9Oord7EpjNK6Am8e7J RbAaFgFVieNd84BWc3CICkRILNqRCVEiKHFy5hMWkDCngJPE/7lyENP1JHZc/8UKYctLNG+d zTyBUWgWko5ZSMpmISlbwMi8ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdcLzezRC81pXQTIyiw 2V1UdjA2H1I6xCjAwajEw7uAOT9MiDWxrLgy9xCjJAeTkiiv2fe8MCG+pPyUyozE4oz4otKc 1OJDjBIczEoivNfYgMp5UxIrq1KL8mFS0hwsSuK8c7/4hgkJpCeWpGanphakFsFkZTg4lCR4 rdmBGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGLwAbXlyQmFucmQ6RP8Woy7Hgx+21TEIsefl5qVLi vJEggwRAijJK8+DmgBNSKsfEV4ziQG8J8/KDVPEAkxncpFdAS5iAlhw9mQ2ypCQRISXVwBjO duN+w18elgUvD+/SPPgxjKEgJPrtdf+I/00CV6IVfIIVLr9/tPZ1iqpTqZ3178NTOo0blJl6 1j8VWstxqFJ1+5SfsSa6FzbGGLzuE/1dmXPE3NpNwuCvg6N05YU5vu8mfTpbpf09/+25D3+D s/cZ5FwV3Cfu0B3W3Hxe+GWzXfE0T8m1r5VYijMSDbWYi4oTAcg3TVgjAwAA Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] RFC 3961 AEAD extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 18:20:16 -0000 On 12/14/2015 12:54 PM, Benjamin Kaduk wrote: > But, the network can be improved with "just" a "small matter of > programming", so it seems beneficial to provide a way that these new > enctypes could be used by non-GSSAPI protocols. AES-GCM and chacha20-poly1305 are already well-specified; beyond assigning enctype numbers that can be negotiated alongside RFC 3961 enctypes, I'm not sure we really have anything to say. In the GSS layer, we of course have to specify what to use as the IV and what to provide as additional data. But all that is very much specific to GSS. From nobody Mon Dec 14 10:33:31 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7821E1B2D32 for ; Mon, 14 Dec 2015 10:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMVSaprxWlYT for ; Mon, 14 Dec 2015 10:33:28 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C68D1B2CAF for ; Mon, 14 Dec 2015 10:33:27 -0800 (PST) X-AuditID: 12074424-f79216d00000156e-1f-566f0b76c4af Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 93.D2.05486.67B0F665; Mon, 14 Dec 2015 13:33:26 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id tBEIXQJd018862; Mon, 14 Dec 2015 13:33:26 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tBEIXMHM020419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Dec 2015 13:33:25 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id tBEIXM9B007466; Mon, 14 Dec 2015 13:33:22 -0500 (EST) Date: Mon, 14 Dec 2015 13:33:22 -0500 (EST) From: Benjamin Kaduk To: Greg Hudson In-Reply-To: <566F085A.1050503@mit.edu> Message-ID: References: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> <1D0FEA3E-A8D7-4702-B228-FAF697BB427A@padl.com> <5666640C.2050401@mit.edu> <20151208223656.GD23318@localhost> <7216FCF9-6F37-4D23-8A36-F75E7ED4EB7C@padl.com> <566E54F3.9030308@mit.edu> <719F56B0-BA00-40BA-8902-41F08B03E3FC@padl.com> <566F085A.1050503@mit.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixG6nolvGnR9mMGe+jcXRzatYLO5e+s/u wOSxZMlPJo+5H6axBDBFcdmkpOZklqUW6dslcGUsu3WZpeA2R8Wqm40sDYyf2boYOTkkBEwk blw+xwhhi0lcuLceLC4ksJhJ4utiwS5GLiB7I6PEy2ebmSGcQ0wSKz8uZIRwGhgl1m26C9bC IqAtcXRGDxOIzSagIjHzzUawuIiAosTvlW/BVjALuEq8WHQWrEZYQE+iccp+oDgHB6eAusSb Z9wgYV4BR4kbC16yQcy/zizx8uw8VpCEqICOxOr9U1ggigQlTs58wgIxU0ti+fRtLBMYBWch Sc1CklrAyLSKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI11wvN7NELzWldBMjOFRdVHYwNh9SOsQo wMGoxMO7gDk/TIg1say4MvcQoyQHk5Ior9n3vDAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrzR XEDlvCmJlVWpRfkwKWkOFiVx3rlffMOEBNITS1KzU1MLUotgsjIcHEoSvDdBGgWLUtNTK9Iy c0oQ0kwcnCDDeYCGXwcbXlyQmFucmQ6RP8WoKCXOuwgkIQCSyCjNg+sFp5LdTKqvGMWBXhHm FQAmFiEeYBqC634FNJgJaPDRk9kgg0sSEVJSDYxrFHun2/Wq/LuwMePSWy+huwH3fkhMPbO9 6mXm0ZP6+nNmrdwbyqHIxM91bl32ihcPXHIPJLw9YHHD0GfCoY83lfSD9+UIX+9caXCLb2eZ fYmxVO5zri1LDyuEWbguUNwU4r3Tal6I+f3F6y32Tpuz4Ezd4q87K/eGPtn0s8LlKOPnGNsl +5RLlFiKMxINtZiLihMBMVwKaAADAAA= Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] RFC 3961 AEAD extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 18:33:29 -0000 Hi Greg, On Mon, 14 Dec 2015, Greg Hudson wrote: > On 12/14/2015 12:54 PM, Benjamin Kaduk wrote: > > But, the network can be improved with "just" a "small matter of > > programming", so it seems beneficial to provide a way that these new > > enctypes could be used by non-GSSAPI protocols. > > AES-GCM and chacha20-poly1305 are already well-specified; beyond > assigning enctype numbers that can be negotiated alongside RFC 3961 > enctypes, I'm not sure we really have anything to say. > > In the GSS layer, we of course have to specify what to use as the IV and > what to provide as additional data. But all that is very much specific > to GSS. The text you quoted and your reply seem like something of a non-sequitur to me. I suppose I did leave out the key fact that the OpenAFS/rxgk case is currently using raw 3961 crypto for its bulk data protection. rxgk does have its own enctype negotiation scheme, though someone would need to do an audit to ensure that the "token master key" is not used anywhere without the appropriate key derivation to ensure global uniqueness. -Ben From nobody Mon Dec 14 12:07:38 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3889A1B2E7B for ; Mon, 14 Dec 2015 12:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fIaApxQ5Krz for ; Mon, 14 Dec 2015 12:07:35 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0131.outbound.protection.outlook.com [207.46.100.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C060B1B2E7A for ; Mon, 14 Dec 2015 12:07:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HRhiZmFySDixt34cwmaye5uevmxWqm3W9kw//OO0O/4=; b=ORBFfoHqYA3NyQ4bcGIkIfINZ7hw+nDKpNeu7EDzq+duXPC83kifp5sSg93QandJv/vGtDJf3YhMVfmjMeN10dUM2Y2mWoKX0dfgV35ISLbR8u8ZClP2/n75Dnd3Fx3uFN6ZcMU1SZmiDULmXl8tNF04NS2I6b/d4FFqNi6LkrE= Received: from BY1PR03MB1417.namprd03.prod.outlook.com (10.162.127.147) by BY1PR03MB1419.namprd03.prod.outlook.com (10.162.127.149) with Microsoft SMTP Server (TLS) id 15.1.355.16; Mon, 14 Dec 2015 20:07:34 +0000 Received: from BY1PR03MB1417.namprd03.prod.outlook.com ([10.162.127.147]) by BY1PR03MB1417.namprd03.prod.outlook.com ([10.162.127.147]) with mapi id 15.01.0337.024; Mon, 14 Dec 2015 20:07:33 +0000 From: Michiko Short To: "kitten@ietf.org" Thread-Topic: Re: I-D Action: draft-ietf-kitten-pkinit-freshness-02.txt Thread-Index: AdE2qsQH/rg7B5bwQ5u1U6ATweH9xQ== Date: Mon, 14 Dec 2015 20:07:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=michikos@microsoft.com; x-originating-ip: [2001:4898:80e8:a::8c] x-microsoft-exchange-diagnostics: 1; BY1PR03MB1419; 5:8dk2zvjX//ce7e4+a3YYrF3xhNZM7crIh0cPB7tFeKEl7HtJ7NRd+hyTRNNlH1eGc4QyxGNay+dSMmFFLDjtqUvj49mXBSP6FicLbGgSwEAHSWAvNlxPCbVz/YN6ezpiPtvfxvWk1AIzwPR8pIV7Tw==; 24:b7r+vnx7gpcwvn1EfVnTi2aXofymnSGoPb3fLlryf1xYWKPH7auAIB3/PpV5LTH2+Wph9+TPTEsXkBm+4FDb+27M3uUbzIt4z0xIYI9zkyw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR03MB1419; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(10201501046)(61426038)(61427038); SRVR:BY1PR03MB1419; BCL:0; PCL:0; RULEID:; SRVR:BY1PR03MB1419; x-forefront-prvs: 0790FB1F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(164054003)(199003)(5004730100002)(105586002)(10090500001)(76576001)(5005710100001)(10400500002)(86362001)(10290500002)(97736004)(5002640100001)(81156007)(122556002)(450100001)(106356001)(189998001)(33656002)(8990500004)(107886002)(110136002)(5001960100002)(92566002)(19580395003)(1730700002)(99286002)(74316001)(86612001)(77096005)(586003)(6116002)(790700001)(102836003)(15975445007)(54356999)(19625215002)(1096002)(1220700001)(558084003)(5008740100001)(101416001)(87936001)(16236675004)(230783001)(2351001)(50986999)(5003600100002)(19300405004)(40100003)(2501003)(2900100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR03MB1419; H:BY1PR03MB1417.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY1PR03MB14176FFA4442805542E7463AD0ED0BY1PR03MB1417namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2015 20:07:33.8100 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR03MB1419 Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 20:07:37 -0000 --_000_BY1PR03MB14176FFA4442805542E7463AD0ED0BY1PR03MB1417namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > In 5., there?s a missing space after the comma after Sam?s second acknow= ledgement. Yep, I will add a space in the next version. Thanks, Michiko Short --_000_BY1PR03MB14176FFA4442805542E7463AD0ED0BY1PR03MB1417namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> In 5.,  there?s a missing space after t= he comma after Sam?s second acknowledgement.

 

Yep, I will add a space in the next version.=

 

 

 

Thanks,

Michiko Short

 

--_000_BY1PR03MB14176FFA4442805542E7463AD0ED0BY1PR03MB1417namp_-- From nobody Mon Dec 14 16:30:24 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051A91A8865 for ; Mon, 14 Dec 2015 16:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zy2ASex1P2SZ for ; Mon, 14 Dec 2015 16:30:17 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0107.outbound.protection.outlook.com [207.46.100.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D46C1A88ED for ; Mon, 14 Dec 2015 16:30:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tSTTMv97mMJRDMUqDtljCLGMfbLIFl0PR+Tc643blPY=; b=XziSkNObGCulU7w7+n/fIFIvSWWN1T48qWEQMPrZ/iiB0cIQLdxcHj02/3Gw3MO+npM2J76QryB3uWjS4G3vB7H32hQu1y/R520ielGESOj5cXmriFbqeNP1LLVZ8dPERl32hNQWfEN4+YxkkINBJuL+qz9zc9Xxw1DGAb82lG0= Received: from BLUPR03MB470.namprd03.prod.outlook.com (10.141.78.142) by BLUPR03MB472.namprd03.prod.outlook.com (10.141.78.153) with Microsoft SMTP Server (TLS) id 15.1.355.16; Tue, 15 Dec 2015 00:30:13 +0000 Received: from BLUPR03MB470.namprd03.prod.outlook.com ([10.141.78.142]) by BLUPR03MB470.namprd03.prod.outlook.com ([10.141.78.142]) with mapi id 15.01.0337.024; Tue, 15 Dec 2015 00:30:13 +0000 From: Seth Moore To: Greg Hudson , "kitten@ietf.org" Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-02.txt Thread-Index: AQHRNGJXQ62ls/5e+kustfLbV5KnX57IGfGAgAMVfEA= Date: Tue, 15 Dec 2015 00:30:12 +0000 Message-ID: References: <20151211222125.4545.47509.idtracker@ietfa.amsl.com> <566CC2AB.2060906@mit.edu> In-Reply-To: <566CC2AB.2060906@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=sethmo@microsoft.com; x-originating-ip: [2001:4898:80e8:9::475] x-microsoft-exchange-diagnostics: 1; BLUPR03MB472; 5:x6I+wkg1Dz4sJtFSsxy4kILMgnnTgd94oP+7b1HrBVbXk1XhsDpyVbs/9mBqUaiTHwuT9W63t+8vvZHNk8Sm39Xt5cOZpM1VZn9Y7TyVzgqzxzd18MduTh8m/D/1aqCmYjudumPRQXYMEjvj6Zjl1g==; 24:nUzeQ62YLQapbYiFz5wT18HO5kzsMiloj2o8a+qVdo76q+OmS5M+CLAwhGOBJn4q2XnjFXMKPwzroxySqKAZbeo6fZGEF8dfpu/57Sgq/Po= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB472; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR03MB472; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB472; x-forefront-prvs: 07915F544A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(377454003)(189002)(51914003)(199003)(13464003)(8990500004)(1096002)(5004730100002)(76176999)(5005710100001)(101416001)(2950100001)(87936001)(122556002)(230783001)(40100003)(5008740100001)(10290500002)(92566002)(5002640100001)(10400500002)(5003600100002)(586003)(2501003)(86362001)(2900100001)(2171001)(77096005)(107886002)(33656002)(11100500001)(86612001)(5001770100001)(97736004)(81156007)(106116001)(76576001)(74316001)(6116002)(50986999)(54356999)(102836003)(189998001)(106356001)(19580395003)(10090500001)(105586002)(1220700001)(99286002)(5001960100002)(19580405001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB472; H:BLUPR03MB470.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2015 00:30:12.9154 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB472 Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 00:30:23 -0000 Thanks for the feedback, Greg. > -----Original Message----- > From: Kitten [mailto:kitten-bounces@ietf.org] On Behalf Of Greg Hudson > Sent: Saturday, December 12, 2015 4:58 PM > To: kitten@ietf.org > KDC_ERR_PREAUTH_FAILED has been changed to > KDC_ERR_PREAUTH_EXPIRED as I requested. However, it still talks vaguely > about including a freshness token in the error, which I noted as a proble= m in > my August 17 feedback. >=20 > In RFC 4120, the e-data field is an octet string whose form and semantics > depend on the error code, with speculation that it might contain TYPED-DA= TA > (a presumption which we have since abandoned). Only > KDC_ERR_PREAUTH_REQUIRED has a specified e-data format in RFC 4120; > that format is METHOD-DATA, which is a SEQUENCE OF PA-DATA. >=20 > RFC 6113 section 5.4.4 implicitly forces all error e-data to be in METHOD= -DATA > form if the error might occur in response to a FAST request. Fair point. Michiko and I had a chat, and we agree it would be clearer to j= ust=20 add an explicit note that the e-data is a METHOD-DATA which contains an=20 entry containing the PA_AS_FRESHNESSS octet string. This would be in sectio= n 2.2 "Generation of KRB_ERROR Message". This should avoid implementation Confusion. > In my August 17 feedback, I suggested: > > One alternative is to use KDC_ERR_PREAUTH_EXPIRED from RFC 6113. > > There is no specification for including METHOD-DATA in such an error, > > so the client would have to restart from scratch, without the benefit > > of a newly valid freshness token. But I think that is okay; > > recovering from a delay which resulted in a not-so-fresh freshness > > token should not be a common scenario. >=20 > I still think that is the simplest thing to do. There is no need to opti= mize > round-trips for such an uncommon scenario. At a minimum, I think clients > should be allowed to respond to KDC_ERR_PREAUTH_EXPIRED by restarting > with an unauthenticated AS-REQ. It would be a little simpler, sure. However, it seems overly pessimistic to= do=20 so. I'm not sure we know enough about possible implementations to state that the expired error will truly be rare. In addition, any time a client p= asses expired freshness to a KDC, it seems safe to assume that the client will wa= nt a new freshness token. Why not just supply it to them? Cheers, Seth From nobody Mon Dec 14 23:33:16 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00AC11B2BEB for ; Mon, 14 Dec 2015 23:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75xjhs2EzNwg for ; Mon, 14 Dec 2015 23:33:13 -0800 (PST) Received: from hr2.samba.org (hr2.samba.org [IPv6:2a01:4f8:192:486::147:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDB571B2BC6 for ; Mon, 14 Dec 2015 23:33:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=samba.org; s=42627210; h=Date:Message-ID:From:Cc:To; bh=MnJDxRW3X3iLx28K6G0VouEyaKdPsLF4t0kD9u1/Vpk=; b=aMLr9rytCWnjyBfEq7Eb/7Yz3pwnvXu6+DH1lc879DYjhnkeZ2SFAKyBLgJqlyLsCQ3frixjtR04FQybldfnrsc0LJGaX0f28m+ohU7r5XrXl9bBqiWckOgnibtmOm1r4xTgRROcLE47Cc+EiRKkAbVDGWe48t246PeWeadC6/M=; Received: from [127.0.0.2] (localhost [127.0.0.1]) by hr2.samba.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim) id 1a8k6r-00040G-TZ; Tue, 15 Dec 2015 07:33:22 +0000 To: Benjamin Kaduk , Luke Howard References: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> <1D0FEA3E-A8D7-4702-B228-FAF697BB427A@padl.com> <5666640C.2050401@mit.edu> <20151208223656.GD23318@localhost> <7216FCF9-6F37-4D23-8A36-F75E7ED4EB7C@padl.com> <566E54F3.9030308@mit.edu> <719F56B0-BA00-40BA-8902-41F08B03E3FC@padl.com> From: Stefan Metzmacher Openpgp: id=A3D192CE44EF412517BCED646A739B025C6B98D4 X-Enigmail-Draft-Status: N1110 Message-ID: <566FC22F.1070909@samba.org> Date: Tue, 15 Dec 2015 08:33:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1oQg6D2OsEWe8TRIrA0mRM5LjSt961nSq" Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] RFC 3961 AEAD extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 07:33:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1oQg6D2OsEWe8TRIrA0mRM5LjSt961nSq Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Benjamin, >> * No string-to-key function or associated checksum types will make mos= t non-AEAD usages fail >> * IV must be non-NULL on call to encrypt/decrypt >> * AEAD encryption types unavailable except through krb5_encrypt_iov_iv= ec API >> * Encryption type enumerate APIs hide any AEAD types unless the consum= er is RFC 4537 >> >> Jeff: would be good to hear your thoughts on how useful GCM/etc are fo= r >> non-GSS-API use (e.g. OpenAFS). >=20 > I'm not Jeff, but I am a coauthor on the rxgk-afs specs [0,1] that woul= d > be applicable for OpenAFS. We only use GSS-API for a single negotiatio= n > loop in which the AFS server essentually functions as a kerberos KDC, > vending a ticket-analogue ("token") that is used to authenticate > subsequent connections. The "session key" contained in that token (cal= led > the "token master key") is not used directly; instead a unique transpor= t > key is generated for each connection using PRF+ (this is section 8.3 of= > [0]). It is these subsequent connections that perform bulk data transf= er, > and one would expect that GCM/etc would provide some speed benefit, to = the > extent that the network stack is not the bottleneck. (The OpenAFS rx > stack is notoriously non-performant, particularly for links with large > RTT.) But, the network can be improved with "just" a "small matter of > programming", so it seems beneficial to provide a way that these new > enctypes could be used by non-GSSAPI protocols. You may want to have a look at https://msdn.microsoft.com/en-us/library/cc246482.aspx to see how aes-ccm-128 and aes-gcm-128 are used in SMB3. It also uses GSSAPI to do the authentication and do custom crypto based on the authentication session key. metze --1oQg6D2OsEWe8TRIrA0mRM5LjSt961nSq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJWb8IzAAoJEA219WEoab1WBRIP/RUE7ShjUoi+dPSm+GymmRm+ QWTMjNrocLFrWZCRWo8PbmLTd3PN7pz7LzCl6/0/TJT4DJjqYVrjByIEH4nE8z1O mOISNAKMSNhMza2ai+P08HzuErEs714fzMHPorRPE82pljQVqPT/1zBER6FDPOBv Poau/6FH3H0ViCOT1tWeLGqUXD4lBjXSKN9ImH+de7bZQC4VVbhScCxpR/nf4K7o xil4mA0YqrQmtSBcvunjbyYA/fNFwmMcuBDs9WbxruU9tBcEn0nZueEKJgivH+FH 03MX4Z1XGO1ayftNw+fL+IYI157bwWL+KF5taaafWPmgJ8kWZ1jQUESxcBpY2Kaa hXVILCBVfCMWo/Bb8/mTnCcmDjH17QYGHYxuydFyxEE6yfYBfeZpMcbgzk8t8kMA VomT7sWNcbQ/5an7/zWI+GQfmcEWDVcZbwJdwRS6Ai8f9eLkiCBr30NFEdbg6H7/ TshG220Xcgyt6GJh+0RZQ3ooIbKg5APtKg8m+s3xSrcZv1RBw9WKAuokvfUM2XRf cPL0qKwDznHaFSfeYjwHySGSKPbS/PF+9w780ScadRoep0XzxBEoQmC1b2SUDWFB uwrxVBztNIuWVwCydY2FzG0Gyw6bxVM8oEIXoC6tKSf5jt5JtB8Pjzy3fWh7iG9N nTDWi0XAkGzVsJg8uKxc =AiFQ -----END PGP SIGNATURE----- --1oQg6D2OsEWe8TRIrA0mRM5LjSt961nSq-- From nobody Tue Dec 15 00:06:52 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CB01A6FEF for ; Tue, 15 Dec 2015 00:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6-c8OTZpiUw for ; Tue, 15 Dec 2015 00:06:49 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 340801A6FA6 for ; Tue, 15 Dec 2015 00:06:48 -0800 (PST) Received: by us.padl.com with ESMTP id tBF86fkD007989; Tue, 15 Dec 2015 03:06:44 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luke Howard In-Reply-To: <566FC22F.1070909@samba.org> Date: Tue, 15 Dec 2015 19:06:39 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> <1D0FEA3E-A8D7-4702-B228-FAF697BB427A@padl.com> <5666640C.2050401@mit.edu> <20151208223656.GD23318@localhost> <7216FCF9-6F37-4D23-8A36-F75E7ED4EB7C@padl.com> <566E54F3.9030308@mit.edu> <719F56B0-BA00-40BA-8902-41F08B03E3FC@padl.com> <566FC22F.1070909@samba.org> To: Stefan Metzmacher X-Mailer: Apple Mail (2.3096.5) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.9 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] RFC 3961 AEAD extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 08:06:51 -0000 Thanks Metze, very useful pointer. Out of interest do you know what = their nonces look like? I=92m surprised they say the nonce formation is = implementation-specific as they do not appear to be using different keys = for each direction (so the implementations would need to cooperate to = avoid repeating nonces). (FWIW: SMB appears to use HMAC-SHA256 as the KDF hash function for = GCM/CCM rather than CMAC.) =97 Luke > On 15 Dec 2015, at 6:33 PM, Stefan Metzmacher wrote: >=20 > You may want to have a look at > https://msdn.microsoft.com/en-us/library/cc246482.aspx > to see how aes-ccm-128 and aes-gcm-128 are used in SMB3. > It also uses GSSAPI to do the authentication and do custom crypto > based on the authentication session key. -- www.lukehoward.com soundcloud.com/lukehoward From nobody Tue Dec 15 00:49:12 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D541A00E4 for ; Tue, 15 Dec 2015 00:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSHhKC1AH9JY for ; Tue, 15 Dec 2015 00:49:09 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 888161A00CA for ; Tue, 15 Dec 2015 00:49:06 -0800 (PST) Received: by us.padl.com with ESMTP id tBF8n0Ya009820; Tue, 15 Dec 2015 03:49:04 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luke Howard In-Reply-To: Date: Tue, 15 Dec 2015 19:48:59 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <283A1C5E-9357-4C3B-A140-C8BFE79F2255@padl.com> References: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> <1D0FEA3E-A8D7-4702-B228-FAF697BB427A@padl.com> <5666640C.2050401@mit.edu> <20151208223656.GD23318@localhost> <7216FCF9-6F37-4D23-8A36-F75E7ED4EB7C@padl.com> <566E54F3.9030308@mit.edu> <719F56B0-BA00-40BA-8902-41F08B03E3FC@padl.com> <566FC22F.1070909@samba.org> To: Stefan Metzmacher X-Mailer: Apple Mail (2.3096.5) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.9 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] RFC 3961 AEAD extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 08:49:11 -0000 > On 15 Dec 2015, at 7:06 PM, Luke Howard wrote: >=20 > Thanks Metze, very useful pointer. Out of interest do you know what = their nonces look like? I=92m surprised they say the nonce formation is = implementation-specific as they do not appear to be using different keys = for each direction (so the implementations would need to cooperate to = avoid repeating nonces). Sorry this was a bit misleading =96 what I meant to say is that, for = GCM, you want to have a completely deterministic IV construction in = order to not be limited to 2^32 invocations. But maybe this is not an = issue for SMB3. =97 Luke= From nobody Tue Dec 15 01:31:57 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D961A0222 for ; Tue, 15 Dec 2015 01:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znRKlQyxtfNI for ; Tue, 15 Dec 2015 01:31:54 -0800 (PST) Received: from hr2.samba.org (hr2.samba.org [IPv6:2a01:4f8:192:486::147:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335A71A0210 for ; Tue, 15 Dec 2015 01:31:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=samba.org; s=42627210; h=Date:Message-ID:From:Cc:To; bh=uS6AsPdn8v4DknFm05Dw3SyPrBLHhjTFwFpiGuMovnI=; b=LrYb9a29zFhzEyrA/w6WxqZNndr77MbFjgdZi5IdHzLgL6J1huygE+ZfcMuGBOIyidoSVvx0K8s5jhasyxew3V9bmXtl1iaH6Kl6/JwhSxxUkN8ixsv2+0ox8PPXIbED15SJagMHL+Ps4ijHkFgJR3Pn5GXW7p1IgXpoE0MH9FE=; Received: from [127.0.0.2] (localhost [127.0.0.1]) by hr2.samba.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim) id 1a8lxj-00053B-Pr; Tue, 15 Dec 2015 09:32:03 +0000 To: Luke Howard References: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> <1D0FEA3E-A8D7-4702-B228-FAF697BB427A@padl.com> <5666640C.2050401@mit.edu> <20151208223656.GD23318@localhost> <7216FCF9-6F37-4D23-8A36-F75E7ED4EB7C@padl.com> <566E54F3.9030308@mit.edu> <719F56B0-BA00-40BA-8902-41F08B03E3FC@padl.com> <566FC22F.1070909@samba.org> From: Stefan Metzmacher Openpgp: id=A3D192CE44EF412517BCED646A739B025C6B98D4 X-Enigmail-Draft-Status: N1110 Message-ID: <566FDE01.1090300@samba.org> Date: Tue, 15 Dec 2015 10:31:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TLqxODrAwdf6tgAm0FrmGoqiLMLCrQxTR" Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] RFC 3961 AEAD extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 09:31:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TLqxODrAwdf6tgAm0FrmGoqiLMLCrQxTR Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Luke, > Thanks Metze, very useful pointer. Out of interest do you know what the= ir nonces look like? I=92m surprised they say the nonce formation is impl= ementation-specific as they do not appear to be using different keys for = each direction (so the implementations would need to cooperate to avoid r= epeating nonces). >=20 > (FWIW: SMB appears to use HMAC-SHA256 as the KDF hash function for GCM/= CCM rather than CMAC.) There's a encryption and a decryption key. https://git.samba.org/?p=3Dsamba.git;a=3Dblob;f=3Dlibcli/smb/smbXcli_base= =2Ec#l5565 Windows uses the nonce like this: 8 byte counter 8 byte session id Depending on the algorithm the nonce is then truncated. Samba uses this: 8 byte counter low 8 byte counter high The high value is random and truncated by the algorithm nonce size. See: https://git.samba.org/?p=3Dsamba.git;a=3Dblob;f=3Dlibcli/smb/smbXcli_base= =2Ec#l5737 https://git.samba.org/?p=3Dsamba.git;a=3Dblob;f=3Dlibcli/smb/smbXcli_base= =2Ec#l2974 metze --TLqxODrAwdf6tgAm0FrmGoqiLMLCrQxTR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJWb94EAAoJEA219WEoab1WLSsP/iDo1qAxGD7PtJ3g7+vJQUpx 882bHVGtK3pOHpoWaDOhEOGMiYVvpGKj4C+tuU8DUPBJpCFASqEf9EQplp/t0ejU KTFol33puXpdtllez4EiyfkLydQ4rVle0lCDHHPHGqXRTcCa6Xz8cv9LWvlmWWzp fGKIRkfKOQ+owEKV945VhJ3FM0YA/M47bZOV0E6Yd5o02Mj5NEdvmy/bwjbA0GOG ABRKNIiTMRr3vBCYa+alSH1jflkFIRsDEQLGz4BGsxmIqor2/NoJlTIWGnGMYf7c 5Ff1eZ2P4FkQOHvCIjE68gs9d+mxqMROuYbKzW/oVJeiMBAJ2ir5RIxWjneCT/FO OnlSuQlcteIBx6Ln9PAWs2TKdPFOTT/KVSp4IbvIm7qPvJvRZjZSbo3+zDhxuMoB /O18SzEPAuXVfETzFu7u62qHNLY+m55Ouq+JtX6k5JqhrpqlyTp5glDxb9TcB22z /xXA2pP4ik9uFkWZ2pjvIhq6XIzAeUveZL10nXQn9yHmiADn7pMZFKfkJsOPwlUO ryPgZAU0wjn5wtZ7KseIf1fU1JC1CQO7gua3bFQlvX/6jXE5Ez3zpBXJU/6pUi9r xlL42LHICazB9dIKfxTcFJpmWKG5mg5ypEo6rUkoq8YoysmVDPV8vXd+WkhSkCPQ WQbKf1S/Do2uA6oWy7IG =Ag/F -----END PGP SIGNATURE----- --TLqxODrAwdf6tgAm0FrmGoqiLMLCrQxTR-- From nobody Tue Dec 15 01:48:17 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5311A0398 for ; Tue, 15 Dec 2015 01:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKfD99Pvlooh for ; Tue, 15 Dec 2015 01:48:14 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 498711A039B for ; Tue, 15 Dec 2015 01:48:14 -0800 (PST) Received: by us.padl.com with ESMTP id tBF9m7UY011743; Tue, 15 Dec 2015 04:48:12 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luke Howard In-Reply-To: <566FDE01.1090300@samba.org> Date: Tue, 15 Dec 2015 20:48:05 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> <1D0FEA3E-A8D7-4702-B228-FAF697BB427A@padl.com> <5666640C.2050401@mit.edu> <20151208223656.GD23318@localhost> <7216FCF9-6F37-4D23-8A36-F75E7ED4EB7C@padl.com> <566E54F3.9030308@mit.edu> <719F56B0-BA00-40BA-8902-41F08B03E3FC@padl.com> <566FC22F.1070909@samba.org> <566FDE01.1090300@samba.org> To: Stefan Metzmacher X-Mailer: Apple Mail (2.3096.5) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.9 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] RFC 3961 AEAD extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 09:48:15 -0000 Hi Metze, > There's a encryption and a decryption key. Ah, thanks Metze, I=92d somehow missed that in [MS-SMB2]. Well, all is = good then =96 sorry for the distraction! =97 Luke= From nobody Wed Dec 16 09:35:42 2015 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2CAF1A6F0B; Wed, 16 Dec 2015 09:35:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151216173540.27123.55493.idtracker@ietfa.amsl.com> Date: Wed, 16 Dec 2015 09:35:40 -0800 Archived-At: Cc: kitten@ietf.org, kitten-chairs@ietf.org, draft-ietf-kitten-rfc4402bis@ietf.org Subject: [kitten] Barry Leiba's No Objection on draft-ietf-kitten-rfc4402bis-02: (with COMMENT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 17:35:41 -0000 Barry Leiba has entered the following ballot position for draft-ietf-kitten-rfc4402bis-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-kitten-rfc4402bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- There is one thing I'd like to discuss here (lower-case "discuss"): This document obsoletes RFC 4402 and reclassifies that document as historic. We don't have a clear sense of what "historic" means and how it interacts with "obsolete", so let me start with how I look at it: I think that a newer version of a protocol specification makes the old version of that protocol obsolete. I think that a protocol (but not a version) that is no longer recommended for use might become historic. I think that if we have a protocol called ABCDP, and we make a new protocol called LMNOP that replaces ABCDP, we might likely make ABCDP historic. I think that if we then have an updated version of LMNOP, that obsoletes the earlier version... but it doesn't make it historic. So I question whether the "reclassifies as historic" is the right thing here or not. 4402 will be marked "obsolete", and that should be enough. From nobody Wed Dec 16 14:19:17 2015 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8BA91A9022; Wed, 16 Dec 2015 14:19:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151216221914.18222.1590.idtracker@ietfa.amsl.com> Date: Wed, 16 Dec 2015 14:19:14 -0800 Archived-At: Cc: kitten@ietf.org, kitten-chairs@ietf.org, draft-ietf-kitten-rfc4402bis@ietf.org Subject: [kitten] Ben Campbell's No Objection on draft-ietf-kitten-rfc4402bis-02: (with COMMENT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 22:19:15 -0000 Ben Campbell has entered the following ballot position for draft-ietf-kitten-rfc4402bis-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-kitten-rfc4402bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I would have found a "changes from 4402" section helpful. I concur with Barry's comment concerning obsoleting vs changing to historical. From nobody Thu Dec 17 04:39:39 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490091B2C03 for ; Thu, 17 Dec 2015 04:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ko9Rf1JSlr_W for ; Thu, 17 Dec 2015 04:39:36 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B293D1B2BF9 for ; Thu, 17 Dec 2015 04:39:34 -0800 (PST) Received: by us.padl.com with ESMTP id tBHCdSaP032016; Thu, 17 Dec 2015 07:39:32 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luke Howard In-Reply-To: Date: Thu, 17 Dec 2015 23:39:26 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <272D27BE-E869-4EEC-A1AA-6C714259EB9F@padl.com> References: <1FE17382-E1A9-4CF1-ADFF-0786427C982E@padl.com> <1D0FEA3E-A8D7-4702-B228-FAF697BB427A@padl.com> <5666640C.2050401@mit.edu> <20151208223656.GD23318@localhost> <7216FCF9-6F37-4D23-8A36-F75E7ED4EB7C@padl.com> <566E54F3.9030308@mit.edu> <719F56B0-BA00-40BA-8902-41F08B03E3FC@padl.com> <566F085A.1050503@mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3096.5) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.9 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] RFC 3961 AEAD extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 12:39:37 -0000 > On 15 Dec 2015, at 5:33 AM, Benjamin Kaduk wrote: >=20 > I suppose I did leave out the key fact that the OpenAFS/rxgk case is > currently using raw 3961 crypto for its bulk data protection. rxgk = does > have its own enctype negotiation scheme, though someone would need to = do > an audit to ensure that the "token master key" is not used anywhere > without the appropriate key derivation to ensure global uniqueness. Right, I took a quick look at your code/draft, the authenticator and = packets are fine (the IV can contain the sequence number, where seq=3D0 = for the authenticator). But token encryption may need more care. =E2=80=94 Luke= From nobody Thu Dec 17 06:03:53 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11181B2DE4; Thu, 17 Dec 2015 06:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSFhm8qgJWqF; Thu, 17 Dec 2015 06:03:48 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F1961B2DE9; Thu, 17 Dec 2015 06:03:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=299; q=dns/txt; s=iport; t=1450361028; x=1451570628; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=La5aM+ADwTB3a/u9mq9jI+F407eUAOXiO7F45iW0laA=; b=QgOiLXN0YymUO/XnOhMcRfeWQ66RwoCWlGz+uAKfeiU/yXicw9YiJ5wQ fARozhxtboH4SfPwlv3L8hhysLjEezcb30NFQUV3rwEwKt2Ztt9qqGhWh tBrQNoIVgVhA9lHQBX8w8TJRV+/Y2iY2h9p64aSbKRXt6jMtRsU7pq08E 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AQB8v3JW/4wNJK1egzqBPwa7UYIZA?= =?us-ascii?q?Q2BYoYNAoE1OBQBAQEBAQEBgQqENQEBBDo/EAIBCDYQMiUCBAENBYgvvS4BAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEYhlYBhH2JQAEEkweDdgGNR50cASABAUKCRIFAc?= =?us-ascii?q?oN0gQgBAQE?= X-IronPort-AV: E=Sophos;i="5.20,441,1444694400"; d="scan'208";a="219006880" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Dec 2015 14:03:47 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id tBHE3lnr019624 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 17 Dec 2015 14:03:47 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 17 Dec 2015 08:03:46 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Thu, 17 Dec 2015 08:03:46 -0600 From: "Alvaro Retana (aretana)" To: Barry Leiba , The IESG Thread-Topic: Barry Leiba's No Objection on draft-ietf-kitten-rfc4402bis-02: (with COMMENT) Thread-Index: AQHROCgz0qS3JhL6ZUeh/dUyBtm3857PR+qA Date: Thu, 17 Dec 2015 14:03:46 +0000 Message-ID: References: <20151216173540.27123.55493.idtracker@ietfa.amsl.com> In-Reply-To: <20151216173540.27123.55493.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.5] Content-Type: text/plain; charset="us-ascii" Content-ID: <66D3F29B18DCE449B55AA6BDA77B169E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "kitten@ietf.org" , "kitten-chairs@ietf.org" , "draft-ietf-kitten-rfc4402bis@ietf.org" Subject: Re: [kitten] Barry Leiba's No Objection on draft-ietf-kitten-rfc4402bis-02: (with COMMENT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 14:03:51 -0000 On 12/16/15, 12:35 PM, "iesg on behalf of Barry Leiba" wrote: >So I question whether the "reclassifies as historic" is the right thing >here or not. 4402 will be marked "obsolete", and that should be enough. I agree. Alvaro. From nobody Thu Dec 17 06:05:43 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8721B2D0B; Thu, 17 Dec 2015 06:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6cOAjaFCtgb; Thu, 17 Dec 2015 06:05:33 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BBD81B2C24; Thu, 17 Dec 2015 06:05:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 58CFBBEA4; Thu, 17 Dec 2015 14:05:25 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kieSddAilOM4; Thu, 17 Dec 2015 14:05:23 +0000 (GMT) Received: from [10.87.48.95] (unknown [86.46.31.96]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3CB72BEA1; Thu, 17 Dec 2015 14:05:22 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1450361122; bh=O+4I5/fFAjVA1upmmJpZUcni3SDNcTOB+TtWySwfkNg=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=P2aDvjvgFiwoblTKORNUTGaTlIGnaJo6MjZPzP36AM5UPWJMOV379uHBJxNoV8p7r 0803bi4VcmB7YG+qt7RXU/PiO12zrK3pwrA+5LSD4jbzbwTybmMM42gWHf1HHr0rbm xiP4CEsYDHzSpRV/vyJtimdEYVXV4yXKc643iuUE= To: "Alvaro Retana (aretana)" , Barry Leiba , The IESG References: <20151216173540.27123.55493.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5672C121.7090500@cs.tcd.ie> Date: Thu, 17 Dec 2015 14:05:21 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "kitten@ietf.org" , "kitten-chairs@ietf.org" , "draft-ietf-kitten-rfc4402bis@ietf.org" Subject: Re: [kitten] Barry Leiba's No Objection on draft-ietf-kitten-rfc4402bis-02: (with COMMENT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 14:05:37 -0000 On 17/12/15 14:03, Alvaro Retana (aretana) wrote: > On 12/16/15, 12:35 PM, "iesg on behalf of Barry Leiba" > wrote: > >> So I question whether the "reclassifies as historic" is the right thing >> here or not. 4402 will be marked "obsolete", and that should be enough. > > I agree. OTOH what harm is there is just leaving it as the WG wanted? I see none. S. > > Alvaro. > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From nobody Thu Dec 17 06:35:27 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 332B51B2DFA; Thu, 17 Dec 2015 06:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufaIsnKFVxeW; Thu, 17 Dec 2015 06:35:22 -0800 (PST) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA2F1B2DE5; Thu, 17 Dec 2015 06:35:22 -0800 (PST) Received: by mail-vk0-x22b.google.com with SMTP id a189so47366275vkh.2; Thu, 17 Dec 2015 06:35:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=W9j4T7WJqYi1LNhsCiL0V1Z2Ts2rImmFsBBhavdnxRo=; b=Id3f3BLfBCYLzbgQLVGZ0pWRw2Bm5FloNcLga8f8Kw4UEuAc7PMYrQQiUE4aW4rwh/ Tuhd5OVZdPbN6dhci6+9cYPlG5qUmEk2WD3gRt9STw47v41OXBn1KrGiuTiq3APpr+3f YWhKYumYOKJ3Wo39bkfkqvXjBXVspctyGT3V8Jyp/xf/OFCcJWm0+I1wVoriS29Fguce 3rnddNvqduagN7bXl3a0GIINWDLysklgLO8Bd9y4MTjXwMtMhA6jdgFgFaTxYQOJUrJ9 WIIPVbAt7xNIs6woOMOdMJtVeViQIR3ja9upFiX9XKmGakaj+DdBSqepMRL5/pCsUqnc izFQ== MIME-Version: 1.0 X-Received: by 10.31.188.200 with SMTP id m191mr39106807vkf.102.1450362921433; Thu, 17 Dec 2015 06:35:21 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.31.182.211 with HTTP; Thu, 17 Dec 2015 06:35:21 -0800 (PST) In-Reply-To: <5672C121.7090500@cs.tcd.ie> References: <20151216173540.27123.55493.idtracker@ietfa.amsl.com> <5672C121.7090500@cs.tcd.ie> Date: Thu, 17 Dec 2015 09:35:21 -0500 X-Google-Sender-Auth: 8pvhk40fqKVkwHyhFBYAHfZwCyo Message-ID: From: Barry Leiba To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "kitten@ietf.org" , "kitten-chairs@ietf.org" , "draft-ietf-kitten-rfc4402bis@ietf.org" , The IESG Subject: Re: [kitten] Barry Leiba's No Objection on draft-ietf-kitten-rfc4402bis-02: (with COMMENT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 14:35:23 -0000 >>> So I question whether the "reclassifies as historic" is the right thing >>> here or not. 4402 will be marked "obsolete", and that should be enough. > > OTOH what harm is there is just leaving it as the WG > wanted? I see none. The possible harm is that someone seeing that 4402 is Historic might think that the *protocol* described in 4402 is Historic, and that's not what we mean. That's why Obsoletes and Historic are different things. Barry From nobody Thu Dec 17 06:41:33 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDB41B2E4C; Thu, 17 Dec 2015 06:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCZoJRJ0zVU5; Thu, 17 Dec 2015 06:41:30 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FAED1B2E52; Thu, 17 Dec 2015 06:41:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AFAB8BE97; Thu, 17 Dec 2015 14:41:28 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTUBJ7ebkUDw; Thu, 17 Dec 2015 14:41:27 +0000 (GMT) Received: from [10.87.48.95] (unknown [86.46.31.96]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E7526BE8F; Thu, 17 Dec 2015 14:41:26 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1450363287; bh=d02bw/atCJVcalRQ95f2pihHzLm4RgDbWsYjfe5zUVM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=2IvvdXaYBkwkK2TPRwmlADK9TRe9Fxab8NqAey+X3gdSBPwQP3/FEgKhxrh1m8qMV g6a26LQGG9CrFBU/WzDHor7tZdRPMeYffonLhjpL60R9QyfPrp6x7izkyswnxWBaJp JEsbLdurMGqjJkbpuD75OkoAh/pSluz98xHr3bhg= To: Barry Leiba References: <20151216173540.27123.55493.idtracker@ietfa.amsl.com> <5672C121.7090500@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5672C996.6020600@cs.tcd.ie> Date: Thu, 17 Dec 2015 14:41:26 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "kitten@ietf.org" , "kitten-chairs@ietf.org" , "draft-ietf-kitten-rfc4402bis@ietf.org" , The IESG Subject: Re: [kitten] Barry Leiba's No Objection on draft-ietf-kitten-rfc4402bis-02: (with COMMENT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 14:41:32 -0000 On 17/12/15 14:35, Barry Leiba wrote: >>>> So I question whether the "reclassifies as historic" is the right thing >>>> here or not. 4402 will be marked "obsolete", and that should be enough. >> >> OTOH what harm is there is just leaving it as the WG >> wanted? I see none. > > The possible harm is that someone seeing that 4402 is Historic might > think that the *protocol* described in 4402 is Historic, and that's > not what we mean. That's why Obsoletes and Historic are different > things. Sure, that's a possible interpretation. My take is that most RFC labels are ambiguous and slowly fluid (like treacle:-) so I don't care much. However in this case the kitten WG interpretation iiuc is that the PRF in 4402 is historic (this one differing substantively even if only in one input bit), so I think we ought all be fine with that. IOW, I think you and they are both correct if by "protocol" in your text one means just the PRF. Nobody is of course saying that Kerberos is historic. (Well, not v5 anyway;-) S > > Barry > From nobody Thu Dec 17 22:42:38 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7CF1B33BD; Thu, 17 Dec 2015 22:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X764NP4H8c_I; Thu, 17 Dec 2015 22:42:36 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 323851B33B9; Thu, 17 Dec 2015 22:42:35 -0800 (PST) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tBI6gRn5024084 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Dec 2015 06:42:28 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tBI6gQvH008140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 Dec 2015 06:42:27 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tBI6gQHh025165; Fri, 18 Dec 2015 06:42:26 GMT Received: from [10.159.95.129] (/10.159.95.129) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 17 Dec 2015 22:42:26 -0800 Message-ID: <5673AB21.8010907@oracle.com> Date: Thu, 17 Dec 2015 23:43:45 -0700 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Stephen Farrell , Barry Leiba References: <20151216173540.27123.55493.idtracker@ietfa.amsl.com> <5672C121.7090500@cs.tcd.ie> <5672C996.6020600@cs.tcd.ie> In-Reply-To: <5672C996.6020600@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "kitten@ietf.org" , "kitten-chairs@ietf.org" , "draft-ietf-kitten-rfc4402bis@ietf.org" , The IESG Subject: Re: [kitten] Barry Leiba's No Objection on draft-ietf-kitten-rfc4402bis-02: (with COMMENT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2015 06:42:38 -0000 On 12/17/15 07:41 AM, Stephen Farrell wrote: > > On 17/12/15 14:35, Barry Leiba wrote: >>>>> So I question whether the "reclassifies as historic" is the right thing >>>>> here or not. 4402 will be marked "obsolete", and that should be enough. >>> OTOH what harm is there is just leaving it as the WG >>> wanted? I see none. >> The possible harm is that someone seeing that 4402 is Historic might >> think that the *protocol* described in 4402 is Historic, and that's >> not what we mean. That's why Obsoletes and Historic are different >> things. > Sure, that's a possible interpretation. My take is that > most RFC labels are ambiguous and slowly fluid (like > treacle:-) so I don't care much. > > However in this case the kitten WG interpretation iiuc > is that the PRF in 4402 is historic (this one differing > substantively even if only in one input bit), so I think > we ought all be fine with that. IOW, I think you and they > are both correct if by "protocol" in your text one means > just the PRF. > > Nobody is of course saying that Kerberos is historic. (Well, > not v5 anyway;-) Yes, your differentiation is correct. There was a least one vendor that had implemented 4402 as specified and could not interoperate. We want to make clear that the previous PRF is not to be relied upon (albeit to no fault of its own). Shawn. -- From nobody Sat Dec 19 16:45:22 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45811ACE74 for ; Sat, 19 Dec 2015 16:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Zn6lNMXXLtI for ; Sat, 19 Dec 2015 16:45:19 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D6401ACE72 for ; Sat, 19 Dec 2015 16:45:18 -0800 (PST) Received: by us.padl.com with ESMTP id tBK0jAeo024278; Sat, 19 Dec 2015 19:45:16 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luke Howard In-Reply-To: <5668AF61.60200@mit.edu> Date: Sun, 20 Dec 2015 11:43:12 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151209131557.28382.98569.idtracker@ietfa.amsl.com> <8EE5CA99-AE24-4C9A-9A01-26B3680BE288@mitre.org> <5668AF61.60200@mit.edu> To: "Peck, Michael A" X-Mailer: Apple Mail (2.3096.5) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: BAYES_00,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-08.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2015 00:45:20 -0000 So, what=E2=80=99s the next step for this? I can only speak to Heimdal, = but would be great to get the implementation integrated. =E2=80=94 Luke > On 10 Dec 2015, at 9:46 AM, Greg Hudson wrote: >=20 > On 12/09/2015 08:19 AM, Peck, Michael A wrote: >> This -08 draft hopefully addresses Greg=E2=80=99s feedback = (random-to-key function, cipherstate definition). >=20 > I think these changes are correct and address my feedback. >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten -- www.lukehoward.com soundcloud.com/lukehoward From nobody Sat Dec 19 17:37:58 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811FA1ACEC4 for ; Sat, 19 Dec 2015 17:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.91 X-Spam-Level: X-Spam-Status: No, score=0.91 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDchlPc7tWPN for ; Sat, 19 Dec 2015 17:37:56 -0800 (PST) Received: from sequoia-grove.secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E0FF1ACEC3 for ; Sat, 19 Dec 2015 17:37:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1450575453; x=1451180253; i=jaltman@secure-endpoints.com; q=dns/txt; h=VBR-Info:Subject:To: References:From:Openpgp:Organization:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type; bh=v3jFCDGYNq1Vqq9af0ZeHc GCO93uGppahmg0ZY3lS9o=; b=EL1k+ELboL07clCipXTK4at9OIj4p6nE3ysLPh YcA2+DECW3AyqmdAVaBvUTQJVbHu58NPQXkfJE8EvmCrppKpcGZiwCK3Fc2fCUvq Kv2Uj8uqyAj17oHyYv8TJ2L+EqMusgENookS8ZbWR3yMUPRYUK/c7DDaKDHRkWwG VqQxc= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Sat, 19 Dec 2015 20:37:33 -0500 X-Spam-Processed: sequoia-grove.secure-endpoints.com, Sat, 19 Dec 2015 20:37:33 -0500 Received: from [x.x.x.x] by secure-endpoints.com (Cipher TLSv1:AES-SHA:256) (MDaemon PRO v15.5.3) with ESMTPSA id md50001007129.msg for ; Sat, 19 Dec 2015 20:37:32 -0500 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-MDArrival-Date: Sat, 19 Dec 2015 20:37:32 -0500 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=17967880a8=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org To: kitten@ietf.org References: <20151209131557.28382.98569.idtracker@ietfa.amsl.com> <8EE5CA99-AE24-4C9A-9A01-26B3680BE288@mitre.org> <5668AF61.60200@mit.edu> From: Jeffrey Altman Openpgp: id=FA444AF197F449B24CF3E699F77A735592B69A04; url=http://pgp.mit.edu Organization: Secure Endpoints Inc. Message-ID: <56760658.8060307@secure-endpoints.com> Date: Sat, 19 Dec 2015 20:37:28 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000906070300090008050509" Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-08.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2015 01:37:57 -0000 This is a cryptographically signed message in MIME format. --------------ms000906070300090008050509 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/19/2015 7:43 PM, Luke Howard wrote: > So, what=E2=80=99s the next step for this? I can only speak to Heimdal,= but would be great to get the implementation integrated. >=20 > =E2=80=94 Luke > The document editor(s) request the Working Group chair(s) initiate another Working Group Last Call. Jeffrey Altman --------------ms000906070300090008050509 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DFkwggYVMIIE/aADAgECAhBwEYNf9/MBLeKNZZ697cPvMA0GCSqGSIb3DQEBCwUAMIGmMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5 bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3 MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH NTAeFw0xNTEyMjAwMDAwMDBaFw0xNjEyMjAyMzU5NTlaMIGvMS4wLAYDVQQDDCVQZXJzb25h IE5vdCBWYWxpZGF0ZWQgLSAxNDUwNTc0MTU1Njc5MSswKQYJKoZIhvcNAQkBFhxqYWx0bWFu QHNlY3VyZS1lbmRwb2ludHMuY29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNv bmEgTm90IFZhbGlkYXRlZDEfMB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM0X8uixbo9Tu+sKS20bZeCbN9brFQbtkQ5x /6MrkGsQNTzQ/2WZFJzH89ZoC8auZRFQdA6/yh4wXdCNQ6hBO8Lom26t0LHGhoWtzdkP7MWu YeLMZiuOsC6N6ejHEbtt0KLjphNIUvBVFx5JQzgAwJ1I08LSZg/bIGAVF3SfLOVFu2Iiq5kj psHOv/ECV13fGSvYwBXJN1C1To6wxDgn4pl3m6fFfe4xiVEpc3t6GbKcI+4blK9w76fDaVXw U2uJQAG1UYxbChwocBmb3ka1MlUb2ug3oYBpnufD9zk8u3UqaFlfYyr6/2cr6fqiz1U4+xcb Q3otvVWwzRecpmPEiIcCAwEAAaOCAjIwggIuMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQD AgWgMCAGA1UdJQEB/wQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU2Pc1OxE6 W8hcBZ5L2346cucbFa8wJwYDVR0RBCAwHoEcamFsdG1hbkBzZWN1cmUtZW5kcG9pbnRzLmNv bTBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEWGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cuc3ltYXV0aC5jb20v cnBhMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzU3 ZGU3YTIzOGQ0NWQ4ZDRmYzcxZjhhNWM2YjgxYzkzL0xhdGVzdENSTC5jcmwwTgYIKwYBBQUH AQEEQjBAMD4GCCsGAQUFBzAChjJodHRwOi8vY2FjZXIuc3ltYXV0aC5jb20vbXBraS9zeW1j YzFpbmRzdWJjYWc1LmNydDAfBgNVHSMEGDAWgBRnGbY9pXm7M2DYLVPTjAk9B6wYcDArBgpg hkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGt7pITFgUxMDkyMjA5BgpghkgBhvhFARAF BCswKQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3 DQEBCwUAA4IBAQBvO/+L6Tms91Ed1ZJzgT0y9jBK/Armb6Y/EnR1swCDMqRfBzGSGtzOCuN7 PteBvlaB5vmnwEwiZR/FtsDhhORd8Xy5wdmCunhwPbf0ClnBqichI+4UZNS5fCQTciIqHFxq 7EKuHOQm4/ssEH2Xr8yIpCd+Dx9oPEG7MqUno6oxcIDdur4iNKxOBtjWNiXM7rn733qtuFlw 1jIX3eFIsrBALikTU1UbY2KwfewXbiVaFWY0ysl5uOgfWdmj2xBk7aft/L/fnuyWyeeM9IBg 6vdUjPhmJwtFdEdefgP5cRRdYgG8zgJf8Rq84slkea0bwis8PvKVksJ/k2scaDHzKTe2MIIG PDCCBSSgAwIBAgIQBwKiGoW4S2WeGApu5vWjZTANBgkqhkiG9w0BAQsFADCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRo b3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmlt YXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMTUxMDAxMDAwMDAwWhcNMjUw OTMwMjM1OTU5WjCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0 aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25h IE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW+w0x SSLADLrvTi0XuLQw5TTSrAnuyYkAXfSuExGzE45VzyIYqCAGpv0ly2iUtKCCkA5ulpJE7hW5 tOz6z3k9adScH9wgmg4o1Q21xp468dRlGcCEM02O2orx1ie5A6DR+iicgpNs9w2FfVvpTpli /pNC0u4+s3FXhpdGy98N4caEWrMNj/X0EIoFXZ9oRuwIsFhCgva+LRBGpiQLJ/6YFFODk4Lb 6sA/T6JYYbVLcmkSXzNZ9vmzTABkzoXFhpIMbhzrKM9xqZCpdJl0JOtI4Q5daBKoAWbo7pqy L/g9zbd4JM6lYHzoFj1J8Qe6M74yK8JnoxbHb8DSWpQEwmtFAgMBAAGjggI+MIICOjA3Bggr BgEFBQcBAQQrMCkwJwYIKwYBBQUHMAGGG2h0dHA6Ly9wa2ktb2NzcC5zeW1hdXRoLmNvbTAS BgNVHRMBAf8ECDAGAQH/AgEAMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEF BQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDov L3d3dy5zeW1hdXRoLmNvbS9ycGEwLwYDVR0fBCgwJjAkoCKgIIYeaHR0cDovL3Muc3ltY2Iu Y29tL3BjYTEtZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRU3ltYW50ZWNQS0ktMi0yMTcwHQYDVR0OBBYEFGcZtj2lebszYNgtU9OMCT0HrBhwMIHx BgNVHSMEgekwgeahgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5 OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8 VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQsFAAOCAQEARhnkJ3U7vq/i 2qIUYI8eRJCBaStjSTWN6Xa6n5iPE4HXy/xlG/gOY96UKHT742/YySp6DlSmg64pSvYrUf09 OBK73WNF+2TMPlSGf05CbSO3HQv9+swNjpM1yuVF+c8vf3k9YxjHRyNK9qkUAK1+WVUaiSfb lKCROMb+QJWjYPZduMjFFu2cZmkURhBKynAqb9FQ4CYa01K0R3KLRdK9A7ml3NkI85CrdHCr yqBO8MBO5OC+T5ARYCcMKxzf52zKdbQl55FIqpK0UXVfKZtHFxy9yerPda11I8/yxd9aq7dr yru4XqvVo3DUaPMXepsLoBQ8++iBVmjoz118c7guvDGCBGIwggReAgEBMIG7MIGmMQswCQYD VQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNQIQ cBGDX/fzAS3ijWWeve3D7zANBglghkgBZQMEAgEFAKCCAncwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUxMjIwMDEzNzI4WjAvBgkqhkiG9w0BCQQxIgQg vG0cnr0spEJQ5YEw1nCFr6cn/doO0PqwBnRqQ2wXldEwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBzAYJKwYBBAGCNxAEMYG+MIG7 MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNV BAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk YXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHNQIQcBGDX/fzAS3ijWWeve3D7zCBzgYLKoZIhvcNAQkQAgsxgb6ggbswgaYxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3lt YW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc1 AhBwEYNf9/MBLeKNZZ697cPvMA0GCSqGSIb3DQEBAQUABIIBAB0VxqgIjko1vYZBALd6x277 ATT05MQAPRw94LD4QMP32TY3AoiHMD1d3xO5AOS0NAVWZjgxVr0mWy4b8Jkijy9ygXtvBis0 dtkKdeETUsJE2RU1cg3hUdCenzSa015BtAdNH/DGNX4sJOZuTQAFo5JX2M/NXz2mAEoJuJmL 0Ruy8EEHdzMbh+JjBby4AlopWDFmE8xxbavZ0swYfa2Ii8d2XegcbagQh6DpuEAo0rQ/UXpK uvINwLh6TCKLf62UfQSjBSLftLREg8dVWkTKmxEVVpt8+bewfgw9fmLL2knAGjIwKMzHJpqt n6KWkQrg3C16fUUU/ecz3JJjS3xnAZkAAAAAAAA= --------------ms000906070300090008050509-- From nobody Mon Dec 21 10:24:04 2015 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFF31ABD3B; Mon, 21 Dec 2015 10:24:02 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151221182402.32442.23110.idtracker@ietfa.amsl.com> Date: Mon, 21 Dec 2015 10:24:02 -0800 Archived-At: Cc: kitten-chairs@ietf.org, kitten@ietf.org, draft-ietf-kitten-cammac@ietf.org, The IESG , rfc-editor@rfc-editor.org Subject: [kitten] Protocol Action: 'Kerberos Authorization Data Container Authenticated by Multiple MACs' to Proposed Standard (draft-ietf-kitten-cammac-04.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 18:24:02 -0000 The IESG has approved the following document: - 'Kerberos Authorization Data Container Authenticated by Multiple MACs' (draft-ietf-kitten-cammac-04.txt) as Proposed Standard This document is the product of the Common Authentication Technology Next Generation Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-cammac/ Technical Summary This document specifies a Kerberos Authorization Data container that supersedes AD-KDC-ISSUED. It allows for multiple Message Authentication Codes (MACs) or signatures to authenticate the contained Authorization Data elements. This document updates RFC 4120. Working Group Summary The review process for this document was quite spread out in time, with action occurring in occasional bursts. Almost all of the Kerberos experts who regularly participate in the WG have contributed to reviewing this document at some point in its history, but not necessarily all at the same time. There was a lot of discussion around the time of the initial few revisions, but then a lull in activity. Eventually it got a lot of review comments, which resulted in some (substantive, but relatively minor) changes to the specification. It was unclear what level of review those changes had received, after essentially no comments were received during a WGLC period for the -08, so we solicited further comments at that time, and got thorough review from two Kerberos experts, which the shepherd believes is sufficient. These post-WGLC reviews were largely editorial, but there were four issues of substance that were raised, two of which received heavy There was a second last call for this document - an error was discovered when this was in the RFC editor queue, it was taken back to the WG and is now ready to jump all the hoops again. Document Quality There are not currently any implementations, but Red Hat and MIT plan to collaborate to produce an implementation. MIT has a partial implementation of an en/decoder for the ASN.1 types. (Not sure if that's still correct, but I guess it can't have gotten worse:-) Personnel The document shepherd is Benjamin Kaduk. The irresponsible Area Director is Stephen Farrell. From nobody Mon Dec 21 11:05:14 2015 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC8C1AC3CB; Mon, 21 Dec 2015 11:05:09 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151221190509.8018.89577.idtracker@ietfa.amsl.com> Date: Mon, 21 Dec 2015 11:05:09 -0800 Archived-At: Cc: kitten-chairs@ietf.org, draft-ietf-kitten-rfc4402bis@ietf.org, kitten@ietf.org, The IESG , rfc-editor@rfc-editor.org Subject: [kitten] Protocol Action: 'A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism' to Proposed Standard (draft-ietf-kitten-rfc4402bis-02.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 19:05:10 -0000 The IESG has approved the following document: - 'A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism' (draft-ietf-kitten-rfc4402bis-02.txt) as Proposed Standard This document is the product of the Common Authentication Technology Next Generation Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-rfc4402bis/ Technical Summary This document defines the Pseudo-Random Function (PRF) for the Kerberos V mechanism for the Generic Security Service Application Program Interface (GSS-API), based on the PRF defined for the Kerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context. This document obsoletes RFC 4402 and reclassifies that document as historic. RFC 4402 starts the PRF+ counter at 1, however a number of implementations starts the counter at 0. As a result, the original specification would not be interoperable with existing implementations. Working Group Summary This document is necessary because implementors of RFC 4402 erred when implementing the PRF+ construct, starting the counter variable at zero instead of one. The error was present in multiple releases of a shipping implementation when a second implementor discovered the error in interoperability testing; that second implementor also started the counter variable at zero for compatibility. This document serves to update RFC 4402 and reflect the implementation reality that is deployed and functioning interoperably. It is being published as a Standards Track document to match RFC 4402 which it replaces, as is consistent with most work on Kerberos in the IETF. Document Quality There is strong consensus for this document, which only differs from RFC 4402 in the change of the initial value of the counter variable and the removal of an unneeded and confusing paragraph from the security considerations section. It also adds test vectors, which have been verified by two implementations (MIT and Heimdal Kerberos). The WGLC period was part of a combined WGLC for three "bis" documents, over a period of four weeks. Most of the prominent WG contributors reviewed the document, and no substantive issues were found (though a couple of regressions from RFC 4402 were noted and fixed). Personnel Benjamin Kaduk is the document shepherd. Stephen Farrell is the responsible Area Director. From nobody Sat Dec 26 06:55:21 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752EA1ACCF3; Sat, 26 Dec 2015 06:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lL6G3mH97twJ; Sat, 26 Dec 2015 06:55:19 -0800 (PST) Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) by ietfa.amsl.com (Postfix) with ESMTP id D7B1C1ACCED; Sat, 26 Dec 2015 06:55:18 -0800 (PST) Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0B57B6C0323; Sat, 26 Dec 2015 09:55:18 -0500 (EST) Received: from imshyb01.MITRE.ORG (imshyb01.mitre.org [129.83.29.2]) by smtpvmsrv1.mitre.org (Postfix) with ESMTP id F2A546C031A; Sat, 26 Dec 2015 09:55:17 -0500 (EST) Received: from imshyb01.MITRE.ORG (129.83.29.2) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Sat, 26 Dec 2015 09:55:17 -0500 Received: from na01-bn1-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1130.7 via Frontend Transport; Sat, 26 Dec 2015 09:55:17 -0500 Received: from BY1PR09MB0869.namprd09.prod.outlook.com (10.162.144.143) by BY1PR09MB0870.namprd09.prod.outlook.com (10.162.144.144) with Microsoft SMTP Server (TLS) id 15.1.361.13; Sat, 26 Dec 2015 14:55:14 +0000 Received: from BY1PR09MB0869.namprd09.prod.outlook.com ([10.162.144.143]) by BY1PR09MB0869.namprd09.prod.outlook.com ([10.162.144.143]) with mapi id 15.01.0361.006; Sat, 26 Dec 2015 14:55:14 +0000 From: "Peck, Michael A" To: Jeffrey Altman , "kitten@ietf.org" , "kitten-chairs@ietf.org" Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-08.txt Thread-Index: AQHRMoPIJvi1cRkEEEuJaylhDqyD557CT6gAgADyVICAD9fLAIAADykAgAn5GYA= Date: Sat, 26 Dec 2015 14:55:13 +0000 Message-ID: <0A463374-4AFC-48D8-884E-090441465E2D@mitre.org> References: <20151209131557.28382.98569.idtracker@ietfa.amsl.com> <8EE5CA99-AE24-4C9A-9A01-26B3680BE288@mitre.org> <5668AF61.60200@mit.edu> <56760658.8060307@secure-endpoints.com> In-Reply-To: <56760658.8060307@secure-endpoints.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151217 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mpeck@mitre.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [192.160.51.89] x-microsoft-exchange-diagnostics: 1; BY1PR09MB0870; 5:nEHXWoYRemF5gP1oTNe2A2IMTcNZv61F3EMBXAc+pJs30GYroUcgS2oryCA3qZ77/Hsb1KEyUFnAYSdbJ47o66q+1optDVqEBUmmpuR9nShTgOs1nxXL1fB5pZwIMsR1/iH9VSQvc/8NpF6YE79QOQ==; 24:1QizTOShfQudzN5LYF/3YuOAF3/ncTABXKipQR0o0eBTJrgUQZwbaX19alyHx4OwWhCMNIQfnulgTaW4M3M20Jacz4t+SUrkiwy9BFPnL2A= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR09MB0870; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:BY1PR09MB0870; BCL:0; PCL:0; RULEID:; SRVR:BY1PR09MB0870; x-forefront-prvs: 0802ADD973 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(199003)(479174004)(24454002)(189002)(19580395003)(3846002)(586003)(102836003)(6116002)(2900100001)(77096005)(19580405001)(93886004)(5008740100001)(230783001)(92566002)(2950100001)(1096002)(1220700001)(5002640100001)(66066001)(105586002)(106356001)(106116001)(122556002)(81156007)(11100500001)(2501003)(36756003)(40100003)(5004730100002)(83716003)(87936001)(50986999)(33656002)(101416001)(10400500002)(99286002)(54356999)(76176999)(107886002)(5001770100001)(86362001)(97736004)(2201001)(5001960100002)(189998001)(4001350100001)(83506001)(82746002)(7059030)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR09MB0870; H:BY1PR09MB0869.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: mitre.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <07264DD260E7A041ABC03C5A7D2D2D12@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Dec 2015 14:55:13.3869 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR09MB0870 X-OriginatorOrg: mitre.org Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-08.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2015 14:55:20 -0000 VGhhbmtzIGFsbCBmb3IgdGhlIGZlZWRiYWNrIGFuZCB0aGUgZWZmb3J0cyBwdXQgaW4gdG8gaW1w bGVtZW50IHRoZSBkcmFmdCBhbmQgdmVyaWZ5IHRoZSB0ZXN0IHZlY3RvcnMuDQpXZSByZXF1ZXN0 IHRoYXQgdGhlIGNoYWlycyBpbml0aWF0ZSBhbm90aGVyIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxs IGZvciBkcmFmdC1pZXRmLWtpdHRlbi1hZXMtY3RzLWhtYWMtc2hhMi4NCg0KTWlrZSBQZWNrDQoN Cg0KDQoNCk9uIDEyLzE5LzE1LCA4OjM3IFBNLCAiS2l0dGVuIG9uIGJlaGFsZiBvZiBKZWZmcmV5 IEFsdG1hbiIgPGtpdHRlbi1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBqYWx0bWFuQHNl Y3VyZS1lbmRwb2ludHMuY29tPiB3cm90ZToNCg0KPk9uIDEyLzE5LzIwMTUgNzo0MyBQTSwgTHVr ZSBIb3dhcmQgd3JvdGU6DQo+PiBTbywgd2hhdOKAmXMgdGhlIG5leHQgc3RlcCBmb3IgdGhpcz8g SSBjYW4gb25seSBzcGVhayB0byBIZWltZGFsLCBidXQgd291bGQgYmUgZ3JlYXQgdG8gZ2V0IHRo ZSBpbXBsZW1lbnRhdGlvbiBpbnRlZ3JhdGVkLg0KPj4gDQo+PiDigJQgTHVrZQ0KPj4NCj4NCj5U aGUgZG9jdW1lbnQgZWRpdG9yKHMpIHJlcXVlc3QgdGhlIFdvcmtpbmcgR3JvdXAgY2hhaXIocykg aW5pdGlhdGUNCj5hbm90aGVyIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsLg0KPg0KPkplZmZyZXkg QWx0bWFuDQo+DQo+DQo= From nobody Sat Dec 26 13:43:54 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A731ACEFB for ; Sat, 26 Dec 2015 13:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MANGLED_STOP=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRNHCMLI23it for ; Sat, 26 Dec 2015 13:43:49 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41ADE1ACEFA for ; Sat, 26 Dec 2015 13:43:47 -0800 (PST) X-AuditID: 12074423-f797f6d0000023d0-51-567f0a121220 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 81.9C.09168.21A0F765; Sat, 26 Dec 2015 16:43:46 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id tBQLhjGq006657; Sat, 26 Dec 2015 16:43:46 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tBQLhgKM018381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 26 Dec 2015 16:43:45 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id tBQLhgCc007748; Sat, 26 Dec 2015 16:43:42 -0500 (EST) Date: Sat, 26 Dec 2015 16:43:42 -0500 (EST) From: Benjamin Kaduk To: Greg Hudson In-Reply-To: <566102DE.5020708@mit.edu> Message-ID: References: <20151203182416.14249.59890.idtracker@ietfa.amsl.com> <8BBA724D-905D-4B7D-BE87-A8748D8A8F3E@mitre.org> <566102DE.5020708@mit.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixG6noivEVR9m0LJYxeLo5lUsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKmLXFqGA1e8Xr9bNZGhjfsHYxcnJICJhIrLn8jwnCFpO4cG89 WxcjF4eQwGImiUVrN7NDOBsZJQ73HmWBcA4xSSy78JcZwmlglLiz8yszSD+LgLZE0+VGsLls AioSM99sZAOxRQQUJX6vfMsIYjMLCEusPzcDrF5YwE/i4p1dQDUcHJwC6hJXntuDmLwCjhKP 50Lt6mWUeDNhCztIuaiAjsTq/VNYQGxeAUGJkzOfsECM1JJYPn0bywRGwVlIUrOQpBYwMq1i lE3JrdLNTczMKU5N1i1OTszLSy3SNdPLzSzRS00p3cQIDkoX5R2Mfw4qHWIU4GBU4uF98aI2 TIg1say4MvcQoyQHk5Io74fjdWFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHgrrwLleFMSK6tS i/JhUtIcLErivHO/+IYJCaQnlqRmp6YWpBbBZGU4OJQkeBdw1IcJCRalpqdWpGXmlCCkmTg4 QYbzAA3fC1LDW1yQmFucmQ6RP8Woy7Hgx+21TEIsefl5qVLivJtAigRAijJK8+DmgJPJbibV V4ziQG8J814CqeIBJiK4Sa+AljABLTk4txpkSUkiQkqqgfFG+c+VZ0Tk7pUsVPqffOTc2UcP di13uKbzbsmk/W979s8p/5jul7d2LlNkq8kyu6PlQcbLpD8VPGVaPO8Cn5rTF5EbE9tm7Ng3 ZZWsHl9SjtemS12RXZKCRX9W1JZOl18YevyHzPMgleOpxe/iQuZYB09Q6i2Z3THLfuX+XWZJ f41txdPXt3QrsRRnJBpqMRcVJwIAgSrT9QEDAAA= Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-07.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2015 21:43:52 -0000 On Thu, 3 Dec 2015, Greg Hudson wrote: > On 12/03/2015 01:32 PM, Peck, Michael A wrote: > > We would appreciate working group feedback on this new finally posted draft. > > > While removing truncation from the PRF output, we also changed (with the goal of simplifying) the PRF computation (end of section 5 / top of page 7). > > I think that's a good change. The old definition performed two HMACs, > the first with a fixed string and the second with the PRF input. The > new definition stuffs the PRF input into the first HMAC along with the > fixed parts. I think I had asked for/suggested this, out of an abundance of caution and a sense of alignment with some other PRF scheme in the sense of having an intermediate Kp. (Maybe in [0]?) I believe the version in the -08 is fine, though -- me-from-2014 was probably overcautious. -Ben [0] http://www.ietf.org/mail-archive/web/kitten/current/msg04692.html From nobody Sat Dec 26 14:05:22 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803301ACF57 for ; Sat, 26 Dec 2015 14:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DY5jvFY4wT8G for ; Sat, 26 Dec 2015 14:05:17 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C38F31ACF54 for ; Sat, 26 Dec 2015 14:05:16 -0800 (PST) X-AuditID: 12074424-f79216d00000156e-e3-567f0f1bea79 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id BF.E1.05486.B1F0F765; Sat, 26 Dec 2015 17:05:15 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id tBQM5Eqr031447; Sat, 26 Dec 2015 17:05:14 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tBQM5B3M022820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 26 Dec 2015 17:05:13 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id tBQM5AvM010432; Sat, 26 Dec 2015 17:05:10 -0500 (EST) Date: Sat, 26 Dec 2015 17:05:10 -0500 (EST) From: Benjamin Kaduk To: Luke Howard In-Reply-To: Message-ID: References: <20151203182416.14249.59890.idtracker@ietfa.amsl.com> <8BBA724D-905D-4B7D-BE87-A8748D8A8F3E@mitre.org> <56679A51.3030700@mit.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-879165757-1451167510=:26829" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IR4hRV1pXmrw8zeDiR1+Lo5lUsFncv/Wd3 YPJYsuQnk8fcD9NYApiiuGxSUnMyy1KL9O0SuDKmLv7DXHCct+L/g++sDYwTuLsYOTkkBEwk Pj+5zwZhi0lcuLceyObiEBJYzCQx+dMJKGcjo8TpplVMEM4hJokZ3xaygLQICTQwShz9wgxi swhoS0x9v4cVxGYTUJGY+WYj2FgRAQWJyfvXAtVwcDALuEn8/QW2WVjAT+LinV1gJZwCNhIz 700Es3kFHCWmT7/ACrHrLaNEy78XTCAJUQEdidX7p7BAFAlKnJz5hAViZoDEk59WExgFZyHJ zELIgISZBdQlGh+cZYOwtSXu32xjW8DIsopRNiW3Sjc3MTOnODVZtzg5MS8vtUjXXC83s0Qv NaV0EyMorNldVHYwNh9SOsQowMGoxMM74VltmBBrYllxZe4hRkkOJiVR3vk89WFCfEn5KZUZ icUZ8UWlOanFhxglOJiVRHgrr9aFCfGmJFZWpRblw6SkOViUxHnnfvENExJITyxJzU5NLUgt gsnKcHAoSfCe4AUaKliUmp5akZaZU4KQZuLgBBnOAzR8LUgNb3FBYm5xZjpE/hSjopQ4bwpI QgAkkVGaB9cLTju7mVRfMYoDvSLMy8gHVMUDTFlw3a+ABjMBDT44txpkcEkiQkqqgbHtURVn gP9Pycf8R6cLZ7A9EcjYv9fB80bjlze1l9P1ljWUfityr7b+yWTnsCaae4a28YrCV+abbx6I fLqIU2TuF7Vl7deOz98m+fZSysbpf7JP373V8OVEc1ytoM0NzVkLc9fE6MtbfLUUt1o24y7X gcfPP7tMvFz7tmLVpeCJpr1Vshw2B5cosRRnJBpqMRcVJwIA/apUDxYDAAA= Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-07.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2015 22:05:19 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-879165757-1451167510=:26829 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 9 Dec 2015, Luke Howard wrote: > > Greg =E2=80=93 what do you think about default enctype ordering, should i= t be > preferred over the 3962 enctypes? I'm not Greg, and this topic is out of scope for the document at hand, but probably merits some discussion. The immediate benefits of these new enctypes are somewhat marginal -- use of encrypt-then-mac-with-confounder instead of encrypt-and-mac-with-confounder is a more well-known secure construction and a wider security margin due to the larger tag, and it allows people to check off the box that they don't use SHA-1. But, the ciphertexts are larger, and there are potential issues if a service ends up with a key for the new enctype but without software that can handle it. For me, that would indicate a pretty gradual adoption scheme -- for a software distribution like MIT krb5 that has regular releases, ship a version that supports the new enctype but doesn't use it by default anywhere, then in the next release start offering it for AS exchanges (i.e., obtaining tickets that are mostly only going to be sent back to the KDC and not to random application servers) and generating keys for it but leave it un-preferred elsewhere, then in the following release consider increasing its priority more generally. I'm not sure whether Heimdal would be able to get away with such a delayed rollout, though. -Ben ---559023410-879165757-1451167510=:26829-- From nobody Sat Dec 26 14:19:37 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B891ACF5E; Sat, 26 Dec 2015 14:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyKnprJuBPds; Sat, 26 Dec 2015 14:19:35 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id C65F41ACF5B; Sat, 26 Dec 2015 14:19:34 -0800 (PST) X-AuditID: 12074422-f79c46d000006aa7-0b-567f1275b857 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 27.8A.27303.6721F765; Sat, 26 Dec 2015 17:19:34 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id tBQMJX77025466; Sat, 26 Dec 2015 17:19:33 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tBQMJUhF025993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 26 Dec 2015 17:19:32 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id tBQMJTDt012185; Sat, 26 Dec 2015 17:19:29 -0500 (EST) Date: Sat, 26 Dec 2015 17:19:29 -0500 (EST) From: Benjamin Kaduk To: "Peck, Michael A" In-Reply-To: <0A463374-4AFC-48D8-884E-090441465E2D@mitre.org> Message-ID: References: <20151209131557.28382.98569.idtracker@ietfa.amsl.com> <8EE5CA99-AE24-4C9A-9A01-26B3680BE288@mitre.org> <5668AF61.60200@mit.edu> <56760658.8060307@secure-endpoints.com> <0A463374-4AFC-48D8-884E-090441465E2D@mitre.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-232330218-1451168369=:26829" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileLIzCtJLcpLzFFi42IRYrdT1y0Tqg8zeL6O1eLa7v2sFkc3r2Kx OH3rObMDs8eSJT+ZPN42XGUPYIrisklJzcksSy3St0vgyrj4egNjQRdXxaXJE9kbGPs4uhg5 OCQETCQ2r3TqYuQEMsUkLtxbz9bFyMUhJLCYSaLvRw87hLORUeLGg5NMEM4hJolLD28yQjgN jBJ7l69nBOlnEdCWeLnvMwuIzSagIjHzzUY2EFtEQF2i73APWJxZIFmi6eVFsLiwgJ/EzslT mEFsTgFbibNfvoDV8Ao4ShzaeRPMFhKYxiSxbpI/iC0qoCOxev8UqBpBiZMzn0DNDJD43jaX cQKj4CwkqVlIUhC2ukTjg7NsELa2xP2bbWwLGFlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Zrq 5WaW6KWmlG5iBAe5i9IOxp8HlQ4xCnAwKvHwvnhRGybEmlhWXJl7iFGSg0lJlHc+T32YEF9S fkplRmJxRnxRaU5q8SFGCQ5mJRHeyqt1YUK8KYmVValF+TApaQ4WJXHeuV98w4QE0hNLUrNT UwtSi2CyMhwcShK8wYJAQwWLUtNTK9Iyc0oQ0kwcnCDDeYCGNwsA1fAWFyTmFmemQ+RPMSpK ifMmgjQLgCQySvPgesFJaDeT6itGcaBXhHk7Qap4gAkMrvsV0GAmoMEH51aDDC5JREhJNTCW nC/Y7eKyd4O8+VSTBwYvrzRPmHig+vvjftnmjGSB48yGhlZxNl9sBOPmrbGV/zW958ymTZa5 Oft6eZys1wmzzU6SXP7iQC+TzBQdzp/+9iW6bnMOXtbdsUw1QGRhrZ5BxONn5pJPOhosJ0Zq bWCMPpJYX3Th/E4lb7bEfc6eSoH/O5SZ1iuxFGckGmoxFxUnAgA+Qc66HQMAAA== Archived-At: Cc: "kitten@ietf.org" , "kitten-chairs@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-08.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2015 22:19:36 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-232330218-1451168369=:26829 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Thanks for all the updates; the diff between the -06 and the -08 looks good. I expect that the chairs will be able to start a new WGLC soon. -Ben On Sat, 26 Dec 2015, Peck, Michael A wrote: > Thanks all for the feedback and the efforts put in to implement the draft= and verify the test vectors. > We request that the chairs initiate another Working Group Last Call for d= raft-ietf-kitten-aes-cts-hmac-sha2. > > Mike Peck > > > > > On 12/19/15, 8:37 PM, "Kitten on behalf of Jeffrey Altman" wrote: > > >On 12/19/2015 7:43 PM, Luke Howard wrote: > >> So, what=E2=80=99s the next step for this? I can only speak to Heimdal= , but would be great to get the implementation integrated. > >> > >> =E2=80=94 Luke > >> > > > >The document editor(s) request the Working Group chair(s) initiate > >another Working Group Last Call. > > > >Jeffrey Altman > > > > > ---559023410-232330218-1451168369=:26829--