From nobody Mon Aug 3 13:05: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 9A5C31B30B0 for ; Mon, 3 Aug 2015 13:05:31 -0700 (PDT) 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_20=-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 i64K-C_61DqQ for ; Mon, 3 Aug 2015 13:05:30 -0700 (PDT) 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 E06DB1ACD9C for ; Mon, 3 Aug 2015 13:05:29 -0700 (PDT) X-AuditID: 1209190c-f79296d000000622-d4-55bfc988e1e7 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 99.72.01570.889CFB55; Mon, 3 Aug 2015 16:05:28 -0400 (EDT) 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 t73K5S2j019215 for ; Mon, 3 Aug 2015 16:05:28 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t73K5Ri1009268 for ; Mon, 3 Aug 2015 16:05:28 -0400 From: Tom Yu To: References: <20150625184429.1312.27540.idtracker@ietfa.amsl.com> Date: Mon, 03 Aug 2015 16:05:26 -0400 In-Reply-To: <20150625184429.1312.27540.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Thu, 25 Jun 2015 11:44:29 -0700") Message-ID: Lines: 25 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsUixG6nottxcn+owYdPRhZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRsPqo0wFjzkqLn1exNbAuIqti5GTQ0LAROLg8k8sELaYxIV7 64HiXBxCAouZJF5NXMQOkhASOMYocfBCLESikUmi8c4BsG42AWmJ45d3MYHYIgKiErO3vAKb JCxgIdF49CojRLODxJpdHWBxFgFViTUt15hABnEK9DNKvD5yg7WLkYODV0BXYltfDEgNjwCn xNn9e1hBbF4BQYmTM5+A9TILaEnc+PeSaQIj/ywkqVlIUgsYmVYxyqbkVunmJmbmFKcm6xYn J+blpRbpGurlZpbopaaUbmIEBRmnJM8OxjcHlQ4xCnAwKvHwfliwL1SINbGsuDL3EKMkB5OS KK/yif2hQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4V88EyvGmJFZWpRblw6SkOViUxHk3/eAL ERJITyxJzU5NLUgtgsnKcHAoSfAagAwVLEpNT61Iy8wpQUgzcXCCDOcBGq4PUsNbXJCYW5yZ DpE/xagoJc7LDpIQAElklObB9cKSwCtGcaBXhHmTQKp4gAkErvsV0GAmoMGXM/aADC5JREhJ NTBGBKfrR3CV1SnuavtysWxTm1DB5YJa47OzTGdc4tp3K/iYxNXv26asdDkRquWYqGMWoeSz 8tPjguu7ds88ISOok7L58Z7/yccan//b6xazS/15YNjhup3pN+T2syoIK8+0U/S+//iRpnNS xv9QPw1tIdHe88ZZp++XXcrNF2QzebQkPvjGm3VKLMUZiYZazEXFiQAeQL/G3QIAAA== Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-cammac-03.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, 03 Aug 2015 20:05:31 -0000 writes: > 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 : Kerberos Authorization Data Container Authenticated by Multiple MACs > Authors : Simo Sorce > Tom Yu > Thomas Hardjono > Filename : draft-ietf-kitten-cammac-03.txt > Pages : 10 > Date : 2015-06-25 > > Abstract: > 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. The multiple MACs are needed > to mitigate shortcomings in the existing AD-KDC-ISSUED container. > This document updates RFC 4120. I believe this addresses the remaining concerns from the previous revision. Chairs, do you think this should go to WGLC now? Thanks. -Tom From nobody Mon Aug 3 16:14: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 6CB861B29BE for ; Mon, 3 Aug 2015 16:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.966 X-Spam-Level: X-Spam-Status: No, score=-0.966 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 ttTxS0c1ME0h for ; Mon, 3 Aug 2015 16:14:43 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2160D1B137B for ; Mon, 3 Aug 2015 16:14:43 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id BB4FD27BC073; Mon, 3 Aug 2015 16:14:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:mime-version:content-type; s= cryptonector.com; bh=ufGJBDDf9daT1Bqbgi7Q3r9GQAk=; b=Iv5QsymHKLs mda88OkWCBAdTvRTy2sLEnJu9V++4Ben1kRev3KKjeVi+2uD1UFbFZm262ksl8k8 lyzrOl6GTnd86BxMrW9ojB/7gD2LsO7cRMCqyNTUa/2a1dzRw5Pfg5M/NK/6ngyW U7uR1jk33H6t6jU0IMuY9Cu3UFHAYWeQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPA id 4B88427BC05D; Mon, 3 Aug 2015 16:14:42 -0700 (PDT) Date: Mon, 3 Aug 2015 18:14:41 -0500 From: Nico Williams To: iana@iana.org Message-ID: <20150803231440.GP2957@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org Subject: [kitten] Registry entry format for draft-ietf-kitten-gssapi-extensions-iana 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, 03 Aug 2015 23:14:44 -0000 draft-ietf-kitten-gssapi-extensions-iana awaits a WGLC, and since -10 is expired, the WGLC awaits submission of -11. Since I'd like to generate them for all the GSS symbols in the various RFCs to submit together with the I-D when it got to the IANA review stage of publication... I needed to know what to generate. And we don't specify much of a format for registration entries. Dear IANA: what sort of submission format would you prefer? Plain text with lines of "field: value" (and multi-line values continued with leading space), tables in xml2rfc-schema XML, text tables as formatted by xml2rfc, JSON, something else? Now's the time to be picky! Before I put much effort into generating the seed registry :) Thanks, Nico -- From nobody Mon Aug 3 17:06: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 56B091B321C for ; Mon, 3 Aug 2015 17:06:27 -0700 (PDT) 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 gDKU9Yca2CA9 for ; Mon, 3 Aug 2015 17:06:25 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E51B21B3227 for ; Mon, 3 Aug 2015 17:06:23 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 63B15B8095; Mon, 3 Aug 2015 17:06:23 -0700 (PDT) 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=iWe2Lk7fxdg7Dc y7BPiLysuoR5I=; b=w5v+68r1VOQ2AtcOh8qcxbHBDuK4wbuquOFl4dHXCImNir JzLwDWVdtwjCopzB76Up8r9EFOQVZ+IBYP8OukokIXrdSD6uJr4O6Obum6cBwicZ MAWUyQUcN6hmq6rrxXzpUdgTg7Sg+iV64LRMPrhYAsK/M9n5fJvLBv5/EMvXQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPA id C8795B806B; Mon, 3 Aug 2015 17:06:22 -0700 (PDT) Date: Mon, 3 Aug 2015 19:06:21 -0500 From: Nico Williams To: iana@iana.org Message-ID: <20150804000621.GQ2957@localhost> References: <20150803231440.GP2957@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150803231440.GP2957@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Registry entry format for draft-ietf-kitten-gssapi-extensions-iana 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, 04 Aug 2015 00:06:27 -0000 A sample registration entry in JSON format: { "binding_of": "GSS_Accept_sec_context", "bindings": "C", "description": "Accept a security context", "object_type": "Function", "reference": "RFC2744", "registration_rules": "IESG Approval", "registration_type": "Instance", "status": "Registered", "symbol_name": "gss_accept_sec_context Accept a security context" } The "reference" field could be an array, either always or if there are multiple references. It could be absent or null or [] (empty array) if there are no references, whichever is preferable. Fields that are not applicable should be left out. Comments? Nico -- From nobody Tue Aug 4 01:36: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 DE5CC1B3704 for ; Tue, 4 Aug 2015 01:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 T3rtmBx4QyXw for ; Tue, 4 Aug 2015 01:36:10 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0726.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::726]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D1D81B372F for ; Tue, 4 Aug 2015 01:36:10 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com; Received: from pc6 (81.151.167.91) by AM2PR07MB0515.eurprd07.prod.outlook.com (10.160.31.20) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 4 Aug 2015 08:35:47 +0000 Message-ID: <001501d0ce90$0b9263a0$4001a8c0@gateway.2wire.net> From: t.p. To: Nico Williams , References: <20150803231440.GP2957@localhost> <20150804000621.GQ2957@localhost> Date: Tue, 4 Aug 2015 09:31:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.91] X-ClientProxiedBy: DB3PR05CA0031.eurprd05.prod.outlook.com (25.160.41.159) To AM2PR07MB0515.eurprd07.prod.outlook.com (25.160.31.20) X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0515; 2:fWlF3d+bSlNPKQaXRx94VKKJYSPd8WUw+Pd23zxQWC+tK3a6Gdh6GeaBHp2Gr0GdzXNedfiFrATCjgOS1XBYfC90bXhUFXbcOMOfGNxB5xRO0bYykkYp7nGq4uS0iOq9wFQlhsBKm9nsGn5x1gVTwznnrMsf1WFQt9rKArcHPNU=; 3:8LxL2xMZbkg3CqWMWSuNqQ3h0xjv6rGOa03wwFHhgcVjIm1lCuTSc32uO8TZ8xEb/2KPBoH82rRwSDbhdYcFnuRZhM5cb/56bsIn6H979Mqnyh/76tlcPluZp2medaSU0lCaN+bVYevzDNAsqEn7oA==; 25:PAW1mZMrbhcVIhW1mYqAzLzhB71NXX9gBX8p57Uwr7sH4yJLlOMXqnLmTKedaSjZ6NymyI8a70+Vf47PjOw2p6xcZuvOYavmshEDIJDSkFgZ/00/Px2MKMkQCn3tMEUlJP3x36LgfcUepMatb6Kb+Ew310jbyL4Bo/+Wdlvst4dirJ3dM254G0TfEChFaKm2K4j8zxNRkn8EL4rBdWEbt9pj0ZY/IzhxCcEkRrd+T1wlhBCcS2Ar+K3a8xMusRPK; 4:lQ0zFVL5B77hgKLQwolXt+JeLRBQpDNHaUd1a1t0n2bfnt1KjLs/diw3sIDGTytp+/wJ0mfRsUL9omSwN8tZaYEEJqrLbrxI70Zr/cK4olN0toYF9sc7nb2jhQbQYzEN9BdXE+62qT9qdokNZJYCxejoi3yj6WhKUstPC+OyJCj+MkL4k9z64m2dqxID0OOxEwRR/38cs8GpjtbXDZEUFkgd2z31giMbOGEAonxB4Exd9yU4+2y6EmAMgAybOTA3o295eYILo7SsZrvcUG7zYbFDw90ELGI4Z//jlkS7/Xk= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM2PR07MB0515; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:AM2PR07MB0515; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0515; X-Forefront-PRVS: 0658BAF71F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(377454003)(13464003)(5001770100001)(81156007)(77156002)(33646002)(40100003)(5001960100002)(92566002)(116806002)(62236002)(62966003)(122386002)(50226001)(50466002)(44736004)(230783001)(189998001)(4001540100001)(5001860100001)(44716002)(5001830100001)(97736004)(14496001)(19580405001)(105586002)(77096005)(84392001)(81686999)(76176999)(23756003)(1556002)(42186005)(46102003)(68736005)(1456003)(61296003)(106356001)(15975445007)(81816999)(66066001)(19580395003)(101416001)(86362001)(64706001)(50986999)(87976001)(47776003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0515; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AM2PR07MB0515; 23:UEkL5afA9tJfTI8PeT5CNujxF2y9qslQCXEO8UD?= =?iso-8859-1?Q?GJ1hKVbz0ShquOUjkhQ+gbvCy1VDhUkkOvaZKpDeNKaItyuW83yeBmY05d?= =?iso-8859-1?Q?WrUEVQ9Nx20/bTErMwVQLBvu6eJafLV7nw1Y36w6FSViZLhJ1a4UKJovAN?= =?iso-8859-1?Q?pBcT63oyWcAoZ6jRUkn40gg+OjkuSxKqZn1CXZH81hOLJp/yZ4lRyBK/46?= =?iso-8859-1?Q?ezmj/PjZ13LSTOroax4cO46ieqv805O8C05z0tWo0rfjWkEOqfOIkeTDda?= =?iso-8859-1?Q?SYxZmP7fFTMWFt09rFo6S/kip7MbUGR0ebdHl2ZgzDqRLJXaIkhbWse1lD?= =?iso-8859-1?Q?6cIirFo0Sp/VVcZ2oFEaQhIzDo+QcxoxkBILdqPbmMQYq0sYYPclylR1CZ?= =?iso-8859-1?Q?c/vD/rk+guPTe+uv0rDVh9LzbUPuHcZWL1LnxhdvEwK4aDONs791rafJBH?= =?iso-8859-1?Q?bme0CONcTE0idHYOYgmuWh1DFL6Nkp9UYjnCD7o2dpW6LpLwB4CFJ7skZ6?= =?iso-8859-1?Q?QCNgk5CeXLe6BFWkXXVA002E4J8e5bIz8lGq5tvwGYeGO8WDuI7OXyZK+g?= =?iso-8859-1?Q?q7uPyT1Te6yLUsnCrQ5F99ZQu1RmRQJMVnjvsK4yTmMTzz396c5BoQY2UC?= =?iso-8859-1?Q?hPfXpjl+4d4oJjIiV7FaWYnizEMAersfMkJNyg+W+iaW7qwBVo49bhyki8?= =?iso-8859-1?Q?0Q8uGV1rSaapoZXUVloEjnz7CRHRGa3PS2//RmVfFnSJg2T17N+UnaYxDK?= =?iso-8859-1?Q?wAUAvzK20ykieHvq3df2PoTe8Fe4G6zYKASr9KeL/vCxRZvbx5HbEzYLX4?= =?iso-8859-1?Q?QySNVW0qiJQovooZWcC0poTN0P0KibxhyZcIsGZg2d9VH9teAHQ7mxfa/L?= =?iso-8859-1?Q?DAtIQcDo/Fte/nJRJYtr7bOscafp+L7m7hH8Ln/wnXdHBom6rF1CKBMD2a?= =?iso-8859-1?Q?QfAKtw0N92qKe9CjRK0c5KU1RPTamtaqLxgrcMnGYOpa8mle7+zszCWEXo?= =?iso-8859-1?Q?UYysczPJd/g4xAXetTEhJpsCHmnqP4xKUVJSFttiDYzYIdbc+ILd8UmtEf?= =?iso-8859-1?Q?UGtGnPIfZQ7P2QMe9sNQ2NmRMVIHJ4cPhFEIPGrt4h0aLUdbOPWuV/HOnM?= =?iso-8859-1?Q?UeYiVPIzvxFQct9JiMnRsCC1z3LXRAqd/XZrXOK02Xa1/1TK/HVVUkEOim?= =?iso-8859-1?Q?sDOZugpqEMGiVx5UG8jvqj19DVv/RAopuUXsmPeNz+irrmP810JtFlOinw?= =?iso-8859-1?Q?0XIo6FBVGA0NBEgxlqooF2DHIXg3v6vJ/FgsePGCRXiBHqIEa3xbexTHwX?= =?iso-8859-1?Q?qDD9XotASMmgyRxUYj1aW8mMKliVkWTedwnr+Abw+/3ofb5K2KZRsGq95w?= =?iso-8859-1?Q?EOT62saiNxEgJXfXXRuSbYBBDkTZS?= X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0515; 5:Y2vffjq1FgefPzd+RsrrYn5wZzbyCqGo79ER7tKa2S+/t3PVCF/Y/kDWhNbElJBJKQ5MkbYDmj4YHRRHDBMmsTyiCHn83CRhX1jP8r71umQpRQhvDumzPt2nLmETl0xiv/MrencRmfoFwly/HngULw==; 24:ITjzEYoZr28isAmxi4u+dOX+SOgzKPiQnSIHxuf+lSMfOZzd/gJobe2YXToN7OXlITbHY0R5Ofm2O5m6x/7lR6LxXLALykvOQLCmj0beHq8=; 20:WgxdhAe7gMvvA4q6luFJb2om15GYXTGHXTeI0c7tAxNMicSb4FqjhGF9jD/QT1Un0QI6baPLc1z+ujU1Q02y3A== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Aug 2015 08:35:47.2789 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0515 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Registry entry format fordraft-ietf-kitten-gssapi-extensions-iana 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, 04 Aug 2015 08:36:16 -0000 ----- Original Message ----- From: "Nico Williams" To: Cc: Sent: Tuesday, August 04, 2015 1:06 AM > A sample registration entry in JSON format: > > { > "binding_of": "GSS_Accept_sec_context", > "bindings": "C", > "description": "Accept a security context", > "object_type": "Function", > "reference": "RFC2744", > "registration_rules": "IESG Approval", > "registration_type": "Instance", > "status": "Registered", > "symbol_name": "gss_accept_sec_context Accept a security context" > } > > The "reference" field could be an array, either always or if there are > multiple references. It could be absent or null or [] (empty array) if > there are no references, whichever is preferable. > > Fields that are not applicable should be left out. > > Comments? Plain text. It is the default, the normal presentation for the IETF, the one that is best understood. And it is the one that JSON use for their IANA entries, such as http://www.iana.org/assignments/jose/jose.xhtml#web-encryption-compressi on-algorithms If it is good enough for JSON, it is good enough for us. Tom Petch > > Nico > -- > From nobody Mon Aug 10 20:32: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 423E31A92AC for ; Mon, 10 Aug 2015 20:32:57 -0700 (PDT) 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_20=-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 8xpHcxjdjIVT for ; Mon, 10 Aug 2015 20:32:55 -0700 (PDT) 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 078251A92A9 for ; Mon, 10 Aug 2015 20:32:54 -0700 (PDT) X-AuditID: 1209190e-f79c76d000002631-25-55c96ce5c0a5 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-3.mit.edu (Symantec Messaging Gateway) with SMTP id 65.EA.09777.5EC69C55; Mon, 10 Aug 2015 23:32:53 -0400 (EDT) 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 t7B3WqgH019437; Mon, 10 Aug 2015 23:32:53 -0400 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 t7B3WnB6010683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Aug 2015 23:32:52 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t7B3WnCB003036; Mon, 10 Aug 2015 23:32:49 -0400 (EDT) Date: Mon, 10 Aug 2015 23:32:49 -0400 (EDT) From: Benjamin Kaduk To: Michiko Short In-Reply-To: Message-ID: References: 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+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrfs052SowfR/0hZHN69isfjXzefA 5LFkyU8mj9Ydf9kDmKK4bFJSczLLUov07RK4MhpefGUu+C9Q0bz/L3MD43/eLkZODgkBE4mr q66xQNhiEhfurWfrYuTiEBJYzCSxtXMFE4SzkVHi/YOlLBDOISaJxrMTWSGcBkaJY9uXMHcx cnCwCGhLrO7MBhnFJqAiMfPNRjYQW0RAS+LDhdNgK5gF1CW+nXnDCFIuLGAmsewcD0iYUyBa 4tSZM2AlvAKOElc/L2aHGH+fUaLl9SdGkISogI7E6v1ToIoEJU7OfAI1U0ti+fRtLBMYBWch Sc1CklrAyLSKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI11gvN7NELzWldBMjOFAl+XYwfj2odIhR gINRiYdXwPNkqBBrYllxZe4hRkkOJiVR3o2pQCG+pPyUyozE4oz4otKc1OJDjBIczEoivK+c gHK8KYmVValF+TApaQ4WJXHeTT/4QoQE0hNLUrNTUwtSi2CyMhwcShK8idlAjYJFqempFWmZ OSUIaSYOTpDhPEDDM0BqeIsLEnOLM9Mh8qcYFaXEeftAEgIgiYzSPLheWCJ5xSgO9Iow71KQ Kh5gEoLrfgU0mAlosF3gCZDBJYkIKakGxnklyee+NZ30f3n1YK7Ypnt/LdgCTQUmtz9mcYg+ 80KdyzWvXqO+TC7+1jIBx76zbmHKPUZppwyWfYgI+bcxq0d9osLy0HBRhX+9zubdixzOvvWu 0Xu8UlYts/F09VXj42tPBv+47h7IoZ+cI/eYxy5BbVeisvZcSxnmi5pvFVRu+FrXTEhXYinO SDTUYi4qTgQAVP3D0P8CAAA= Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-ietf-kitten-pkinit-freshness-01.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, 11 Aug 2015 03:32:57 -0000 Hi Michiko, Thanks for the reminder, and sorry for the long delays (I've been busy moving). I'll get a WGLC started soon. -Ben On Mon, 27 Jul 2015, Michiko Short wrote: > Following up since it would be great to get an IANA number. > > -----Original Message----- > From: Benjamin Kaduk [mailto:kaduk@MIT.EDU] > Sent: Wednesday, June 24, 2015 2:45 PM > To: Michiko Short > Cc: kitten@ietf.org > Subject: Re: draft-ietf-kitten-pkinit-freshness-01.txt > > On Fri, 19 Jun 2015, Michiko Short wrote: > > > I believe we have answered Ben's question about client requesting the > > new feature. Ben, can you confirm? > > Sorry for the delay; it took me longer than I expected to reconstruct the history of the discussion. > > For the curious: I raised the question in http://www.ietf.org/mail-archive/web/kitten/current/msg05630.html of whether we are okay requiring all clients implementing freshness token support to implement the behavior of sending an empty PA_AS_FRESHNESS padata in order to request a freshness token. Michiko acknowledged this in http://www.ietf.org/mail-archive/web/kitten/current/msg05645.html and also mentioned two other options for ways for clients to get freshness tokens, though I don't think either got much discussion. (As described, neither seems particularly appealing, so that seems fine.) > > There was some follow-up discussion starting at http://www.ietf.org/mail-archive/web/kitten/current/msg05665.html , where Sam and Greg seem to agree that the proposed behavior (requiring the clients to explicitly request a freshness token) is acceptable, with varying degrees of enthusiasm. There is still disagreement about whether this sort of negotiation is required, but it seems clear that it is permitted, and no one is raising blocking objections. > > > If so, then I would like to see if we can put this in the queue for WGLC. > > I agree. I was hoping to get out a poll on what potential new work the WG is interested in undertaking (and in what order) before starting the next WGLC, but that seems to be taking much longer than I expected. Stay tuned for more... > > -Ben > From nobody Wed Aug 12 09:04: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 D41D11A21C3; Wed, 12 Aug 2015 09:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] 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 PVoh3OP5Ezqb; Wed, 12 Aug 2015 09:04:12 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E83D1A1A67; Wed, 12 Aug 2015 09:04:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 8AF6D20798; Wed, 12 Aug 2015 12:02:54 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDJxhxPNc_VK; Wed, 12 Aug 2015 12:02:53 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 12 Aug 2015 12:02:53 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8943481BA5; Wed, 12 Aug 2015 12:04:10 -0400 (EDT) From: Sam Hartman To: Phil Lello References: Date: Wed, 12 Aug 2015 12:04:10 -0400 In-Reply-To: (Phil Lello's message of "Wed, 12 Aug 2015 12:21:57 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: kitten@ietf.org, saag@ietf.org, draft-ietf-kitten-sasl-saml-ec@tools.ietf.org Subject: Re: [kitten] [saag] SSH Protocol 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: Wed, 12 Aug 2015 16:04:14 -0000 I think that RFC 4462 plus the SAML ECP mechanism (draft-ietf-kitten-sasl-saml-ec) can do what you're talking about and is probably a fairly good secure way of using a SAML assertion to authenticate to SSH. >>>>> "Phil" == Phil Lello writes: Phil> Hi, I'm currently working on extensions to the SSH Phil> protocol; as I believe the SecSH WG is effectively dormant, is Phil> this list the best place to discuss the proposals? Briefly, I Phil> am seeking to add support for federated/asserted identities to Phil> SSH, for scenarios where the protocol is used as an Phil> application transport (e.g. git, svn). This involves the Phil> client sending a desired username for authentication, along Phil> with a authentication token from a trusted 3rd party. In the Phil> initial implementation, this would be a SAML assertion, Phil> although I intend to make the implementation generic enough to Phil> support other mechanisms. Trust relationships for valid IdPs Phil> would be handled according to local policy. A related Phil> extension will be a formal websocket binding for SSH, and I Phil> expect the reference implementation of this to be a patch to Phil> Gerrit (a git-based code review tool that contains an embedded Phil> Java SSH server). Phil Lello Phil> _______________________________________________ saag mailing Phil> list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From nobody Wed Aug 12 10:55: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 A22A71ABD3A; Wed, 12 Aug 2015 10:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 apimQqncOrX6; Wed, 12 Aug 2015 10:54:54 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 426A91ABD38; Wed, 12 Aug 2015 10:54:54 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t7CHsdt4030467 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 12 Aug 2015 19:54:40 +0200 Date: Wed, 12 Aug 2015 19:54:37 +0200 From: Simon Josefsson To: Sam Hartman Message-ID: <20150812195437.2e03c0c8@latte.josefsson.org> In-Reply-To: References: X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/1XeZTu2_X=gY31QPyqKsrNv"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: kitten@ietf.org, Phil Lello , saag@ietf.org, draft-ietf-kitten-sasl-saml-ec@tools.ietf.org Subject: Re: [kitten] [saag] SSH Protocol 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: Wed, 12 Aug 2015 17:54:57 -0000 --Sig_/1XeZTu2_X=gY31QPyqKsrNv Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Or look into already published RFC 6616 for OpenID in SASL or RFC 6595 on SAML in SASL. SAML-EC avoids the web loop, and may indeed be more relevant depending on use-case. I believe the problem with these mechanisms has been: 1) They are stateless -- if you need to open many connections, or open them often, you need one OpenID/SAML authentication per connection which results in poor user experience. 2) They are tied to a particular federation system. Sometimes this is not a problem, but I imagine sometimes the client/server does not know what system is the most appriate to use until a web loop has been invoked. The OAuth SASL mechanism (long delayed, still being worked on) may also be relevant to look into, but it does not support GSS-API so SSH support is not a given. I believe there is room for improvement in this area, so Phil, please let us know about your progress. If you send me an email I may assist offlist with some advice too. /Simon > I think that RFC 4462 plus the SAML ECP mechanism > (draft-ietf-kitten-sasl-saml-ec) can do what you're talking about and > is probably a fairly good secure way of using a SAML assertion to > authenticate to SSH. > >>>>> "Phil" =3D=3D Phil Lello writes: >=20 > Phil> Hi, I'm currently working on extensions to the SSH > Phil> protocol; as I believe the SecSH WG is effectively dormant, > Phil> is this list the best place to discuss the proposals? > Phil> Briefly, I am seeking to add support for federated/asserted > Phil> identities to SSH, for scenarios where the protocol is used > Phil> as an application transport (e.g. git, svn). This involves > Phil> the client sending a desired username for authentication, > Phil> along with a authentication token from a trusted 3rd > Phil> party. In the initial implementation, this would be a SAML > Phil> assertion, although I intend to make the implementation > Phil> generic enough to support other mechanisms. Trust > Phil> relationships for valid IdPs would be handled according to > Phil> local policy. A related extension will be a formal > Phil> websocket binding for SSH, and I expect the reference > Phil> implementation of this to be a patch to Gerrit (a git-based > Phil> code review tool that contains an embedded Java SSH > Phil> server). Phil Lello > Phil> _______________________________________________ saag > Phil> mailing list saag@ietf.org > Phil> https://www.ietf.org/mailman/listinfo/saag --Sig_/1XeZTu2_X=gY31QPyqKsrNv Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVy4hdAAoJEIYLf7sy+BGd6GIH/iVrthe2ag3LzZ1SSiC3alql h+Z2p5HNQKFNJmxmvtcpjEuT6H5R+6LQThr3bAaPM099Gl3kk/fNiiSGqAjJWkt6 zd1M1zz88GnQQd0A9EDEXvrR2imNsi83/rNIF4QZPNokyq/kFMc5gWsmGy53B/UQ yF7CoY/MdObJk+wEGaNGNxX9iFBJuDGy0GMnyvbIQfzmbZ1PQWxNNeE9uEc9aDTo 6jMjIQ+I3typlMfLjzN+C9gdu86MbYf4w0kCo8UIzgKXu54U7uJ57e2Zfo21n8/i S2pReepYuphNN3u8t7LICw55e/gxel3eG+77kUGlpprxLwtiqsfdp9kIaTVlgkk= =nNob -----END PGP SIGNATURE----- --Sig_/1XeZTu2_X=gY31QPyqKsrNv-- From nobody Wed Aug 12 11:37:05 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 15FED1A8F35; Wed, 12 Aug 2015 11:37:04 -0700 (PDT) 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 I0dCDOq66Zfm; Wed, 12 Aug 2015 11:37:03 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1828C1A8AB1; Wed, 12 Aug 2015 11:37:03 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id C3CC22005693E; Wed, 12 Aug 2015 11:37:02 -0700 (PDT) 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=nf4QvohK5VYur1 CVhFGnYhfoPdM=; b=LaZozSNWam4HyfXAv/a9iV1gSVLi/EXnBbx3TUazdOEst3 /TqhHtceeV4AZTR2eCwC3QgGOVHdThly8FL3k52KqXppn5255s+mT4R60+ZGlMER 8EM6XXk6vpegCoxi6xB4p3O7MggIbQuWiKYKxh/Dkp5mfAFua5E+douwyZ06E= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPA id 25E7720058D13; Wed, 12 Aug 2015 11:37:02 -0700 (PDT) Date: Wed, 12 Aug 2015 13:37:01 -0500 From: Nico Williams To: Simon Josefsson Message-ID: <20150812183657.GG3654@localhost> References: <20150812195437.2e03c0c8@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150812195437.2e03c0c8@latte.josefsson.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org, Sam Hartman , saag@ietf.org, draft-ietf-kitten-sasl-saml-ec@tools.ietf.org Subject: Re: [kitten] [saag] SSH Protocol 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: Wed, 12 Aug 2015 18:37:04 -0000 On Wed, Aug 12, 2015 at 07:54:37PM +0200, Simon Josefsson wrote: > Or look into already published RFC 6616 for OpenID in SASL or RFC 6595 > on SAML in SASL. SAML-EC avoids the web loop, and may indeed be more > relevant depending on use-case. If Phil needs a SAML, one-message authentiation method with no proof of possession, then a new SSHv2 userauth method is probably best (since the GSS userauth method uses MIC tokens for channel binding). Would the SAML token be possible to bind to an SSHv2 session? I would hope so. > I believe the problem with these mechanisms has been: > > 1) They are stateless -- if you need to open many connections, or open > them often, you need one OpenID/SAML authentication per connection which > results in poor user experience. Probably not an issue for SSHv2. > 2) They are tied to a particular federation system. Sometimes this is > not a problem, but I imagine sometimes the client/server does not know > what system is the most appriate to use until a web loop has been > invoked. > > The OAuth SASL mechanism (long delayed, still being worked on) may also > be relevant to look into, but it does not support GSS-API so SSH support > is not a given. See above comment about MIC tokens and channel binding. Also, without a server-side proof of possession the channel binding can only protect against token reuse, and the user will still depend on the use of server host public keys for server authentication (which may not be a problem). Nico -- From nobody Wed Aug 12 18:44: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 9EB2C1B2F01; Wed, 12 Aug 2015 18:44:03 -0700 (PDT) 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 PuoG_FBD7A0H; Wed, 12 Aug 2015 18:44:01 -0700 (PDT) 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 9B4011B2EE9; Wed, 12 Aug 2015 18:44:01 -0700 (PDT) X-AuditID: 1209190e-f79c76d000002631-b5-55cbf660ef23 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-3.mit.edu (Symantec Messaging Gateway) with SMTP id AC.FF.09777.066FBC55; Wed, 12 Aug 2015 21:44:00 -0400 (EDT) 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 t7D1hxYr028987; Wed, 12 Aug 2015 21:43:59 -0400 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 t7D1htj6004541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Aug 2015 21:43:58 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t7D1ht35022933; Wed, 12 Aug 2015 21:43:55 -0400 (EDT) Date: Wed, 12 Aug 2015 21:43:53 -0400 (EDT) From: Benjamin Kaduk To: Simon Josefsson In-Reply-To: <20150812195437.2e03c0c8@latte.josefsson.org> Message-ID: References: <20150812195437.2e03c0c8@latte.josefsson.org> 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+NgFvrHIsWRmVeSWpSXmKPExsUixCmqrJvw7XSoweUbghZHN69isZjS38lk cW/LJXYHZo8lS34yecw8c5E9gCmKyyYlNSezLLVI3y6BK6Pr6Wf2gqtMFf+/HGJrYOxm6mLk 5JAQMJH4vuA0M4QtJnHh3nq2LkYuDiGBxUwSn7q2soIkhAQ2Mkpcvm8MkTjEJLHl/juoqgZG ieMH5rGBVLEIaEtc/HcCrINNQEVi5puNQHEODhEBTYm57RkgYWYBJYldizvByoWByie+Xwa2 mVPASmJZUzcLiM0r4Cix+eUZRoj5MxglTrz6xgiSEBXQkVi9fwpUkaDEyZlPWCCGakksn76N ZQKj4CwkqVlIUgsYmVYxyqbkVunmJmbmFKcm6xYnJ+blpRbpGuvlZpbopaaUbmIEB60k3w7G rweVDjEKcDAq8fBueHQ6VIg1say4MvcQoyQHk5Ior9odoBBfUn5KZUZicUZ8UWlOavEhRgkO ZiUR3qRnQDnelMTKqtSifJiUNAeLkjjvph98IUIC6YklqdmpqQWpRTBZGQ4OJQnezV+AGgWL UtNTK9Iyc0oQ0kwcnCDDeYCG7wWp4S0uSMwtzkyHyJ9i1OVY8OP2WiYhlrz8vFQpoDUgRQIg RRmleXBzYMnmFaM40FvCvB9AqniAiQpu0iugJUxAS9LlToEsKUlESEk1MPqteb1iX1CeqWrC 4ZSy1ce+rkxm3mswd/6juo9Zhue9d307bsqU+faG+W0V9wneURfn2q2//zXitcHmfX+9Mp27 PdbpmYXzHD0e8uuiTLFIL2v/8uI555/KrbqXU/08kuuruQrvwvdvV4Q4XpPlEeZ/Z9XtfFTm 0qcWhWOcO/ddSd1isqMkS0eJpTgj0VCLuag4EQBH39WIEQMAAA== Archived-At: Cc: kitten@ietf.org, saag@ietf.org Subject: Re: [kitten] [saag] SSH Protocol 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, 13 Aug 2015 01:44:03 -0000 On Wed, 12 Aug 2015, Simon Josefsson wrote: > The OAuth SASL mechanism (long delayed, still being worked on) may also > be relevant to look into, but it does not support GSS-API so SSH support > is not a given. The spec just hit AUTH48 today; I am given to understand there are a couple of implementations floating around. -Ben From nobody Thu Aug 13 06:49: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 368F61AC3CB; Thu, 13 Aug 2015 06:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 ZpwEO5Bjwf1z; Thu, 13 Aug 2015 06:49:49 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0775.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::775]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F2ED1A906F; Thu, 13 Aug 2015 06:49:12 -0700 (PDT) Received: from BN1AFFO11FD005.protection.gbl (10.58.52.30) by BN1AFFO11HUB026.protection.gbl (10.58.52.136) with Microsoft SMTP Server (TLS) id 15.1.243.9; Thu, 13 Aug 2015 13:48:48 +0000 Authentication-Results: spf=pass (sender IP is 164.107.81.222) smtp.mailfrom=osu.edu; cryptonector.com; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of osu.edu designates 164.107.81.222 as permitted sender) receiver=protection.outlook.com; client-ip=164.107.81.222; helo=cio-tnc-pf08.osuad.osu.edu; Received: from cio-tnc-pf08.osuad.osu.edu (164.107.81.222) by BN1AFFO11FD005.mail.protection.outlook.com (10.58.52.65) with Microsoft SMTP Server (TLS) id 15.1.243.9 via Frontend Transport; Thu, 13 Aug 2015 13:48:47 +0000 Received: from CIO-KRC-HT04.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by cio-tnc-pf08.osuad.osu.edu (Postfix) with ESMTPS id 149672E007E; Thu, 13 Aug 2015 09:48:47 -0400 (EDT) Received: from CIO-TNC-D2MBX02.osuad.osu.edu ([fe80::3960:dd86:ba2:ad26]) by CIO-KRC-HT04.osuad.osu.edu ([fe80::2d93:5c00:ad4e:861d%10]) with mapi id 14.03.0224.002; Thu, 13 Aug 2015 09:48:45 -0400 From: "Cantor, Scott" To: Nico Williams , Simon Josefsson Thread-Topic: [kitten] [saag] SSH Protocol Extensions Thread-Index: AQHQ1RiM4EkCc0B71keQikYW9uIlvp4I6MWAgAAL2ICAAP68AA== Date: Thu, 13 Aug 2015 13:48:45 +0000 Message-ID: <6B7C7317-467A-4809-ABA3-FF599332F18D@osu.edu> References: <20150812195437.2e03c0c8@latte.josefsson.org> <20150812183657.GG3654@localhost> In-Reply-To: <20150812183657.GG3654@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [140.254.59.150] Content-Type: text/plain; charset="utf-8" Content-ID: <7DA4AB04CCA61841BA0289A1113B4504@osu.edu> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD005; 1:29duy2tHuAbbNOLx9IL3pDgFXjy9imqJyEJ8Dr4SUoBF+x3b4PX4aMSLEeSfYXINAPqREaVOASmTZTEf3R3as26dIwMLZAjsBCQuA9OEXKwKe5YJngyhrquSEqIWTucPU4TAfF43x6UZUaP4uLMRzdbCNbnOPpYd13h6IPedGcyfnr3Qy2H/9n3QQIda1kZVyuNhhwhpF5E5EpclJPWE5bdcBj90QKAzPn52exkFh44jgxOULe2f7c83icXqYKDqzdQecoj2Xc9RNHmgsEh9JNCNKsapBqSwmydoT810q8iNK5aXrwer5R9AaC7qrtrA04UZp63YhFtlvLwY19JvyUqtCqfWpe274C3BCOFrkvo= X-Forefront-Antispam-Report: CIP:164.107.81.222; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(3050300001)(377454003)(189002)(479174004)(199003)(24454002)(2656002)(50986999)(87936001)(36756003)(89122001)(90282001)(109096001)(76176999)(106466001)(50466002)(46102003)(75432002)(5250100002)(23676002)(2950100001)(5001770100001)(88552001)(2900100001)(5001860100001)(19580405001)(6806004)(93886004)(5001830100001)(5001920100001)(33656002)(4001540100001)(5003600100002)(19580395003)(66066001)(82746002)(83716003)(102836002)(54356999)(189998001)(64706001)(77156002)(62966003)(93346002)(106116001)(86362001)(47776003)(92566002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB026; H:cio-tnc-pf08.osuad.osu.edu; FPR:; SPF:Pass; PTR:cio-tnc-pf08.osuad.osu.edu; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB026; 2:U8F3ox6W9nBVWzUpHoMoUYVsqz1dfTSWjslya6ZP2x42+jxftxilJ9UDoWLOyzV3XtEw6n+i2Rb2t8Oy/JkGpugWdyUteKlkqqAzznOPWfnkPCNsPNS6sO6rixPVkpp8YUWa3XKHpSc4nf9aCcW3bO5uu/P2J8r6Nc5BPL5ybnA=; 3:z60m4yTVmHUs+5v0VKHZs+R4DILaY/1h1SWiox2s+Cd9V9Ss5YSZ4c1aeJokje+UkElquxn0RpiBr3vKLdqEBbNBgfZaHhNKSFObZznBMIV5Vs+/YLlb5SOHeRfSOch7eJSZwKx2bUpjorB4tlpcnQhUmTGRhT9V91FmZc0UyxxCugSh/i7WcBec2WN6B8/F7++p4OYz36Fvzs+9pLZ7nH8/MlxzhIy2+KEb1fTZd+MXH7Nz39oEuBhT4csd4AqP; 25:YWn++M45vvdUwuASC77DZRvQXb3IHKGCdEkQXLxGzw3iFcOrsrJez+vz1ZsFSGO0ir8ypasUzVQSwZMosIKNBmWA3TnXTJ97zbH3xZsIrAUOQ8luGrVYDIz/ExJSZ/PRgCsa89l97OpioxHPLjBq9W8PGQW5dKSBHI5Zba4f/Kzxj9UYVL7r8ZJb8QJScfhGREYpyDxU7vl5t1W8zLj59mO2hhP0wsnEa69QqUnxbh9AwaPmhmLHjmwT1CumiTW08zF9TVOJSdbJ9UOePFVXLw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB026; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB026; 20:JFpVlxrPYlF2NrDoLwqDq9UxIf2omy61WUr88Zq+aLaAnpDt88CRKu33FMucV/miXQuSz0woaAyiNDGQNoOtenLBTD9p02VaDDghdjLCal2RmY+WGMH7u9gIjFDn0QF3zoCSyveyBWBc3bZECmDjKLGA1ENPJ+HQEcyJSoWqk1ZgHpd+FqblWz5EQ27Se2hBAFUaBaEuWBsEpcsefODvX/O3weHQM0aMoVF20CSZ+VbiLT1Fa4VxWEr/Qlb5U9ljQPzY5r0/e8EvBXZ7u6unTQbriNVi7ysEhHuGJsgB39D3xDRValhZPBnw5d10sTr5aBAXzzs0mHU2G11MBCUhUJKoN40oN8bqh5wLyCldpGJG0H9ZZifSqJCAGfWTM7r4P2Tfs1RpbFU70rF10m/oQnlZYahfu+i7xaMnCsheo2Rwj+8XmVQJsBpGMwe5uGzet82CMwb6eyae6KYSE7pBULNoNAPrM54Z6kFo1CPs6Qu9j7tt1jfBhuy/A8ejnHCt; 4:N+Yy5cJU6Sn96/heE0OlKJYa6Ymgz9Kg55vJBnEg1ptNjQ82Cc6yzdy/ce3exxeViOQeZu5bH96Z1esGWkwv1xHAeegw0Nn2BT8bboMEUY/iyzt/lSFZrZSDIMEvhkTOt3ZrYz4F+uV5fuk/jBnkyx6o142AmuwhUbjQU3VwYLzMZrtZzWhT52PRGJts/qbda6BBdNROCQfDPavDSSMl/JbI5GvBPTpjuCjTDukkD5nt6QXPEhiVIs7jkp8OvcT1N7BNgFOU7iuozslz9qfcDWDysJrKNaib1uEi9NmiquY= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1AFFO11HUB026; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB026; X-Forefront-PRVS: 0667289FF8 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjFBRkZPMTFIVUIwMjY7MjM6SEVJNzgvcGJhTSt5YlNab0lqc0FhMXhw?= =?utf-8?B?Wm9jZXNGRURab1AzbDVkekVaM1FRSWJHRmhaN1FXRFVGa3hBRWpGSTluL1lV?= =?utf-8?B?Nlc2TDFvVERYN0kzOEllN1dSeHFKTndUVGVkQXNxNStVbWVIWTR6cXIzaVpC?= =?utf-8?B?NlE1dUM3WGR0clVhSUhSanN4NHF0L1J6MDFWNno1Mk5zaUJ1anlodEZLRktr?= =?utf-8?B?VnJ1MXpFL1hBVmdjY3pvNDBkQnNFbmNybFFVdFhGMXhiZVJzSVFQSFVnVEN3?= =?utf-8?B?V2UrMnhObHQ5MzV6NDJtU0lISFgrWnhtbGtLcmE0NWNrcW9zQnExMklBYWhx?= =?utf-8?B?S0o1WXBRWWUyU2JVL0RtT0c0QWNXSTNISFJON2Vya1RJeGdWRVJldEQ0QnZj?= =?utf-8?B?SmM4Ykx5NnRmOEdac1BJL1hXYUJWbk00WU1MMTVTOS9YVWQ5UkYwUXIyMVlq?= =?utf-8?B?d2RnWUVyRDdzYmJoVTYxRDFUbDViTUdIS1JZdzFjRi9PQVpGOFk1UUhRbXlN?= =?utf-8?B?QUlFVktOQWE5cGhnU2ZFUDZJTzI3elNUTzA1dWRGdjRKZEhLRnN0aDNyQldM?= =?utf-8?B?VUcwVU1UNGs4Ym03dC80ekNHYUl5TXJOM3NEdkRnYS9XMFBZTzZXQkpMRVhE?= =?utf-8?B?UkpLVFFxVERUeGZrUjR4bWFQRFB4WjBsdFJjeURIN3Q5WWJ1Zld3dDNabWUw?= =?utf-8?B?Q1ZsdTloU3lDdWtGL1RIVUlLWEhuQmlsbGhBeVNwRXVJeUlJWmNmRjhXOGp2?= =?utf-8?B?dFRaWU5JVFRIZWZQOU5SUm15MEV0ZFVoUm9zM056VWtsL0NXSXNQUXhFb1Jz?= =?utf-8?B?UVR5RDc3VkF4aWZoa1JtbHBDRTdOVFgyQU90WnduK3hrM2lTS2FzdVNMTTlC?= =?utf-8?B?L1g4dW5EK3ZVMlhKd1R3akxlVnBhN1pGVS9Rc2pMdTM5dFlWSVNBc242NVdl?= =?utf-8?B?N3BQcFZpT3ZvcncwNlJsK05yN0VKQWlFUG94ekhzazhzKzNVa3RBck5ucjJR?= =?utf-8?B?SW1RVEVWamQvS0draDhEQk5INW43VUZjb2tCcjZlRnJjRE1zd0VKOVU4VHBP?= =?utf-8?B?cEYweWhlbVRNR3dxMUE3eG5iajE2eFZ3M2UzSkFCV3Q0V0Q1MkxLVU1OSVZF?= =?utf-8?B?dG5WemZaa3dCekFZTzNFQWRaUGxPQlhQbzhCMzF6TEhxcmp0bWYvZkR4WXBx?= =?utf-8?B?cFFMdERVeUpLRXU3cFNJSElEMU5uTVlNczI5Tk1hWURzNGU1Ri9GY0t3alps?= =?utf-8?B?UFNTMytSZlhCc3RscU5EMitHdm9rSk9rSmhKb1VZaHR5U1FWNTRHaHVhL1Mz?= =?utf-8?B?MHB6cnpMa3MwT3hzQy9mOFhoUVJrbjNqSTNuUU9WSkplZStkZzAvUFhBMml0?= =?utf-8?B?dFptZDBSQm0rNkdCQWgyNFV1eXJRRk0zWkJiL1dYMmJpb0wvOU5rbHJ3dzZT?= =?utf-8?B?WGxPT3BMdWhkZEN4UStBbDljN2tzeE03QXh3ckJFRHQwUWVHRHFOS0NIMGFW?= =?utf-8?B?eGhqTDNPb0FLR3JFY1RVRm9FaUkzVzhIbkoySkNGVXJWSisvS0gxMVZpMHMx?= =?utf-8?B?RlprdkJ1WXNZUXJHNXZvemNKTFgvZkJQYTVtV2NBcUE0QVhtRzJYSGVSbGZr?= =?utf-8?B?RTJPckFzTDRsbitneTdWSXVtcHVhZkRhbXlaa3dsTFMrODc4ckU2S05oem9u?= =?utf-8?B?c3ZldzVsODd0MkhwREJ2WnZoREJSQ3VGNzBGWlRBNzFyYU1rNXhrRHZ6ZTky?= =?utf-8?B?MkNWRjM4S3AwSGl0b2tPK29KcXI4aG5GcngvUFEvV292K2duWTFkWnpNemk2?= =?utf-8?B?ekhudThuN3VZZ3lvWU8yYTNIQm05MHhMSjZGRnFyRkFXelJ6K1k1bGtYcnJj?= =?utf-8?Q?SZBxxd1M6uQdU=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB026; 5:aatwZOdSzvfV2Ygeg4ez768RAmE/I0i+70ijOg7ofwC9/eeJE7WoLg5Cr+V6KBD1S6KibIu0rLCdkPoPsF93F95GX5eJwe1vqv1QTEWeOk2UqlDWaQsE+iBBOKNmbkGXNBm361/za1/84BE1WqCvVw==; 24:l6bmfuV3ZU7/PPuOaa8qBqSAnYW7xDyJx1cRiOlbgnpSgSV2A7uMSNNfBNtq4tQXRn72gZnxj5YUjy224ravsWH3ba4aoJfCBWwtuUWC2ZI= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: osu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Aug 2015 13:48:47.7872 (UTC) X-MS-Exchange-CrossTenant-Id: b4d138ca-1815-4a9b-a3a7-130a33b1e692 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=b4d138ca-1815-4a9b-a3a7-130a33b1e692; Ip=[164.107.81.222]; Helo=[cio-tnc-pf08.osuad.osu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB026 Archived-At: Cc: "kitten@ietf.org" , Sam Hartman , "saag@ietf.org" , "draft-ietf-kitten-sasl-saml-ec@tools.ietf.org" Subject: Re: [kitten] [saag] SSH Protocol 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, 13 Aug 2015 13:49:52 -0000 T24gOC8xMi8xNSwgMjozNyBQTSwgIktpdHRlbiBvbiBiZWhhbGYgb2YgTmljbyBXaWxsaWFtcyIg PGtpdHRlbi1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBuaWNvQGNyeXB0b25lY3Rvci5j b20+IHdyb3RlOg0KDQo+T24gV2VkLCBBdWcgMTIsIDIwMTUgYXQgMDc6NTQ6MzdQTSArMDIwMCwg U2ltb24gSm9zZWZzc29uIHdyb3RlOg0KPj4gT3IgbG9vayBpbnRvIGFscmVhZHkgcHVibGlzaGVk IFJGQyA2NjE2IGZvciBPcGVuSUQgaW4gU0FTTCBvciBSRkMgNjU5NQ0KPj4gb24gU0FNTCBpbiBT QVNMLiAgU0FNTC1FQyBhdm9pZHMgdGhlIHdlYiBsb29wLCBhbmQgbWF5IGluZGVlZCBiZSBtb3Jl DQo+PiByZWxldmFudCBkZXBlbmRpbmcgb24gdXNlLWNhc2UuDQo+DQo+SWYgUGhpbCBuZWVkcyBh IFNBTUwsIG9uZS1tZXNzYWdlIGF1dGhlbnRpYXRpb24gbWV0aG9kIHdpdGggbm8gcHJvb2Ygb2YN Cj5wb3NzZXNzaW9uLCB0aGVuIGEgbmV3IFNTSHYyIHVzZXJhdXRoIG1ldGhvZCBpcyBwcm9iYWJs eSBiZXN0IChzaW5jZSB0aGUNCj5HU1MgdXNlcmF1dGggbWV0aG9kIHVzZXMgTUlDIHRva2VucyBm b3IgY2hhbm5lbCBiaW5kaW5nKS4gIFdvdWxkIHRoZQ0KPlNBTUwgdG9rZW4gYmUgcG9zc2libGUg dG8gYmluZCB0byBhbiBTU0h2MiBzZXNzaW9uPyAgSSB3b3VsZCBob3BlIHNvLg0KDQpFeGNlcHQg aXQncyBub3QgZGVmaW5lZCBob3cgb25lIHdvdWxkIGFjcXVpcmUgdGhlIHRva2VuLCBhbmQgdGhh dCdzIG5vdCB0cml2aWFsIHRvIGRvIHByb3Blcmx5LiBJZiBTQU1MIElkUHMgZG9uJ3Qgc3VwcG9y dCB0aGUgcHJvZmlsZSwgdGhlbiB5b3UncmUgbm93aGVyZS4gVGhhdCdzIHRoZSBwcm9ibGVtIHRo ZSBzYW1sLWVjIG1lY2hhbmlzbSB3YXMgYXR0YWNraW5nIGZ1bmRhbWVudGFsbHksIHJldXNlIG9m IGFuIGFwcHJvcHJpYXRlIFNBTUwgcHJvZmlsZSB0byBkbyB0aGUgam9iLg0KDQotLSBTY290dA0K DQo= From nobody Sat Aug 15 13:29: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 0B6211ACDAA for ; Sat, 15 Aug 2015 00:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 8f7glL-ImP4n for ; Sat, 15 Aug 2015 00:52:51 -0700 (PDT) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (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 DBAC61ACDA5 for ; Sat, 15 Aug 2015 00:52:50 -0700 (PDT) Received: by lbbsx3 with SMTP id sx3so56857738lbb.0 for ; Sat, 15 Aug 2015 00:52:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/NZajXdNxebbiv7+EGaxDrfsm3CALP842d7A1jY6EL0=; b=KPK56CpKInsKzBQiC0us5jSZC79jUedoM+I80DuuvopQcuFrQi7fUayaqB93X6ys7F CfhmzbR7OtsYrKU9JNuc4T4uo/IsKOEcanrOwXPVuTYEAKum4Y/tG61BnD0Mzz2dBCK8 Fl+E8sccyDc6ANMsudkjoyuRqo8XNksZBVDjmgCLUe5t/C7kDZDVD9HbTNEydQ4Lpba2 86KaQ2vBImj+0T23ZCLjjhFFEXzuN8+wHnaFlRr4rQv5JjoNju+UG4uxZCCETujC8luZ hEy5ki+FPsS7SjtORTv1hWottH0YrIVwMDxYBtPUfqUfWtR/NRF1SUgfYbTFbxY9vC+S gKfg== X-Gm-Message-State: ALoCoQlu1eP0b3MD4degwjFUS3SeJB6tFtmhuqN6Gommu241q49Zr561iyYnuiTuDmirTyidGu+D MIME-Version: 1.0 X-Received: by 10.112.105.104 with SMTP id gl8mr47269852lbb.81.1439625169250; Sat, 15 Aug 2015 00:52:49 -0700 (PDT) Received: by 10.25.144.193 with HTTP; Sat, 15 Aug 2015 00:52:49 -0700 (PDT) In-Reply-To: <6B7C7317-467A-4809-ABA3-FF599332F18D@osu.edu> References: <20150812195437.2e03c0c8@latte.josefsson.org> <20150812183657.GG3654@localhost> <6B7C7317-467A-4809-ABA3-FF599332F18D@osu.edu> Date: Sat, 15 Aug 2015 08:52:49 +0100 Message-ID: From: Phil Lello To: "Cantor, Scott" Content-Type: multipart/alternative; boundary=001a11347b18d2cd98051d54da5f Archived-At: X-Mailman-Approved-At: Sat, 15 Aug 2015 13:29:35 -0700 Cc: "kitten@ietf.org" , "saag@ietf.org" , "draft-ietf-kitten-sasl-saml-ec@tools.ietf.org" , Sam Hartman Subject: Re: [kitten] [saag] SSH Protocol 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: Sat, 15 Aug 2015 07:52:54 -0000 --001a11347b18d2cd98051d54da5f Content-Type: text/plain; charset=UTF-8 Thanks to everyone for their input. I think my efforts would be better directed at extending the SSH protocol to support SASL; although SASL/GSS binding (RFC5801) is possible in some cases, it isn't always. Is there an industry standard for SASL in C? I'm aware of https://tools.ietf.org/html/draft-newman-sasl-c-api-03 from April 2004 and the GSASL http://www.gnu.org/software/gsasl/ library, but am looking for a standard mechanism where adding new SASL mechanisms is a case of adding a run-time plugin (.so / .dll). Phil Lello On Thu, Aug 13, 2015 at 2:48 PM, Cantor, Scott wrote: > On 8/12/15, 2:37 PM, "Kitten on behalf of Nico Williams" < > kitten-bounces@ietf.org on behalf of nico@cryptonector.com> wrote: > > >On Wed, Aug 12, 2015 at 07:54:37PM +0200, Simon Josefsson wrote: > >> Or look into already published RFC 6616 for OpenID in SASL or RFC 6595 > >> on SAML in SASL. SAML-EC avoids the web loop, and may indeed be more > >> relevant depending on use-case. > > > >If Phil needs a SAML, one-message authentiation method with no proof of > >possession, then a new SSHv2 userauth method is probably best (since the > >GSS userauth method uses MIC tokens for channel binding). Would the > >SAML token be possible to bind to an SSHv2 session? I would hope so. > > Except it's not defined how one would acquire the token, and that's not > trivial to do properly. If SAML IdPs don't support the profile, then you're > nowhere. That's the problem the saml-ec mechanism was attacking > fundamentally, reuse of an appropriate SAML profile to do the job. > > -- Scott > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --001a11347b18d2cd98051d54da5f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks to everyone for their input. I think my e= fforts would be better directed at extending the SSH protocol to support SA= SL; although SASL/GSS binding (RFC5801) is possible in some cases, it isn&#= 39;t always.

Is there an industry standard for SASL in C? I= 9;m aware of https://tools.ietf.org/html/draft-newman-sasl-c-api-03 from April = 2004 and the GSASL http://ww= w.gnu.org/software/gsasl/ library, but am looking for a standard mechan= ism where adding new SASL mechanisms is a case of adding a run-time plugin = (.so / .dll).

Phil Lello

On Thu, Aug 13, 2015 at 2:48 PM, C= antor, Scott <cantor.2@osu.edu> wrote:
On 8/12/15, 2:37 PM, "Kitten on behalf = of Nico Williams" <kitte= n-bounces@ietf.org on behalf of nico@cryptonector.com> wrote:

>On Wed, Aug 12, 2015 at 07:54:37PM +0200, Simon Josefsson wrote:
>> Or look into already published RFC 6616 for OpenID in SASL or RFC = 6595
>> on SAML in SASL.=C2=A0 SAML-EC avoids the web loop, and may indeed= be more
>> relevant depending on use-case.
>
>If Phil needs a SAML, one-message authentiation method with no proof of=
>possession, then a new SSHv2 userauth method is probably best (since th= e
>GSS userauth method uses MIC tokens for channel binding).=C2=A0 Would t= he
>SAML token be possible to bind to an SSHv2 session?=C2=A0 I would hope = so.

Except it's not defined how one would acquire the token, and tha= t's not trivial to do properly. If SAML IdPs don't support the prof= ile, then you're nowhere. That's the problem the saml-ec mechanism = was attacking fundamentally, reuse of an appropriate SAML profile to do the= job.

-- Scott

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

--001a11347b18d2cd98051d54da5f-- From nobody Sun Aug 16 08:25: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 0CCF01A1A39 for ; Sun, 16 Aug 2015 08:25:07 -0700 (PDT) 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_20=-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 Yc0ojDCBlpQd for ; Sun, 16 Aug 2015 08:25:05 -0700 (PDT) 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 49B991A1A2F for ; Sun, 16 Aug 2015 08:25:03 -0700 (PDT) X-AuditID: 1209190e-f79c76d000002631-53-55d0ab4eb325 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-3.mit.edu (Symantec Messaging Gateway) with SMTP id C5.7E.09777.E4BA0D55; Sun, 16 Aug 2015 11:25:02 -0400 (EDT) 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 t7GFP272016520 for ; Sun, 16 Aug 2015 11:25:02 -0400 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 t7GFOx3p017728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 16 Aug 2015 11:25:01 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t7GFOwft010088; Sun, 16 Aug 2015 11:24:58 -0400 (EDT) Date: Sun, 16 Aug 2015 11:24:58 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org Message-ID: 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+NgFtrPIsWRmVeSWpSXmKPExsUixCmqrOu3+kKowZFNehZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxt1pq9kLZnBU/Lh1hrWB8QlbFyMnh4SAicTBC3NYIWwxiQv3 1gPFuTiEBBYzSaxv/wFWJCRwnFFi+RqoxA0micMHbrBAOA2MEpsObAFrZxHQlnjVu4cZxGYT UJGY+WYjWLeIgLDE7q3vwOLCAmYSO35sAKvnFXCUmDyvkR3EFhXQkVi9fwoLRFxQ4uTMJ2A2 s4CWxPLp21gmMPLNQpKahSS1gJFpFaNsSm6Vbm5iZk5xarJucXJiXl5qka6xXm5miV5qSukm RnA4SfLtYPx6UOkQowAHoxIPr8Sh86FCrIllxZW5hxglOZiURHkfRAGF+JLyUyozEosz4otK c1KLDzFKcDArifDq9F4IFeJNSaysSi3Kh0lJc7AoifNu+sEXIiSQnliSmp2aWpBaBJOV4eBQ kuDNXgXUKFiUmp5akZaZU4KQZuLgBBnOAzScF6SGt7ggMbc4Mx0if4pRUUqc99BKoIQASCKj NA+uFxbvrxjFgV4R5mUHaecBpgq47ldAg5mABtvNOAsyuCQRISXVwBiWnldmO+9y8uEcq31d Os9LN2uFVIR0dmXezbm98ttk9ZSMnxfdW60ydrEwpL5S/rIoSlJi66R73paPu88FTpnxs2sW X8pDgdUrpGZen+AvfcnvD4vbhcNanmfPSCk4BSa0x7vbn28P2Z6ip79dQa1S9ovZsiDnA9Pu pc1e/7HDzmRT/D9fJSWW4oxEQy3mouJEAO9+NenSAgAA Archived-At: Subject: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01 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, 16 Aug 2015 15:25:07 -0000 This message begins the Working Group Last Call (WGLC) of "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension" . The WGLC will last two weeks, ending on Sunday, August 30th. The draft is available at: https://tools.ietf.org/html/draft-ietf-kitten-pkinit-freshness-01 Please review the document and send comments to the Working Group mailing list or the co-chairs before the end of the WGLC. Any and all comments on the document are sought in order to access the strength of consensus. Even if you have read and commented on this or earlier versions of the draft, please feel free to comment again. This is particularly important if you found issues with the previous version. As a reminder, comments can be anything from "this looks fine" to "this is a horrible idea"; they can include suggestions for minor editorial corrections to significant editorial changes. - Your Kitten Chairs From nobody Sun Aug 16 08:31: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 262AE1A1AC2 for ; Sun, 16 Aug 2015 08:31:52 -0700 (PDT) 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 o0DFkh9I6EOb for ; Sun, 16 Aug 2015 08:31:50 -0700 (PDT) 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 97ACB1A1ABF for ; Sun, 16 Aug 2015 08:31:50 -0700 (PDT) X-AuditID: 12074422-f79d26d0000026d6-a5-55d0ace569b9 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 58.DE.09942.5ECA0D55; Sun, 16 Aug 2015 11:31:50 -0400 (EDT) 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 t7GFVnmQ009448 for ; Sun, 16 Aug 2015 11:31:49 -0400 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 t7GFVkgj019227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 16 Aug 2015 11:31:49 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t7GFVkP6010946; Sun, 16 Aug 2015 11:31:46 -0400 (EDT) Date: Sun, 16 Aug 2015 11:31:46 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: Message-ID: References: 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+NgFrrOIsWRmVeSWpSXmKPExsUixG6nrvtszYVQg+4FTBZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrStxxgL2rkqJlyobmBcxNHFyMkhIWAise/zXVYIW0ziwr31 bF2MXBxCAouZJN7/3sMO4RxnlOg+95cVwrnBJPGtZSZUpoFRYveKoywg/SwC2hKfL25jArHZ BFQkZr7ZyAZiiwgIS+ze+o4ZxBYWcJa4PfMMO4jNKeAk0TzhPVgvr4CjxPJZ78HiQkD2l9mn weaICuhIrN4/BapGUOLkzCdgNrOAlsTy6dtYJjAKzEKSmoUktYCRaRWjbEpulW5uYmZOcWqy bnFyYl5eapGuqV5uZoleakrpJkZw+Lko7WD8eVDpEKMAB6MSD6/EofOhQqyJZcWVuYcYJTmY lER5H0QBhfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nw6vReCBXiTUmsrEotyodJSXOwKInzbvrB FyIkkJ5YkpqdmlqQWgSTleHgUJLgjV8N1ChYlJqeWpGWmVOCkGbi4AQZzgM0fANIDW9xQWJu cWY6RP4Uo6KUOG8GSEIAJJFRmgfXC0sPrxjFgV4R5l0PUsUDTC1w3a+ABjMBDbabcRZkcEki QkqqgVHLOeV82Ly82IVBNwt3WhrM59stccFc4NPm37+i9u39cXOmeturCzb5M8oL19Y6tSYU 7queHlRiN21tqaiWzutdqYknjv20dtFKt5u/R1dv77Gc6us1PDopoud3/vVY5Ra184F6j3uc 261j6/reB5TWvjPqDnhUMsHY7s5fM9bXtnuZni4VWKXEUpyRaKjFXFScCAD6DXok6gIAAA== Archived-At: Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01 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, 16 Aug 2015 15:31:52 -0000 On Sun, 16 Aug 2015, Benjamin Kaduk wrote: > This message begins the Working Group Last Call (WGLC) of "Public Key > Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness > Extension" . The WGLC will last two > weeks, ending on Sunday, August 30th. The draft is available at: > > https://tools.ietf.org/html/draft-ietf-kitten-pkinit-freshness-01 One minor thing occurred to me while I was reading through prior to starting the WGLC: in section 2, bullet 1, the current text has "without an authenticator which includes the freshness token request to the KDC", which doesn't seem quite right -- this un-preauthenticated AS-REQ does not have a freshness token included in it, but it is intended to request a freshness token from the KDC. So, it might be better to just say "without an authenticator that includes a freshness token" [0]. (It would not be correct to say "with an authenticator that does not include a freshness token", right?) -Ben [0] The RFC Editor would change "which" to "that", since their criterion is that "which" is used when clarifying a property of all occurrences of the class being described, whereas "that" is used when the additional clause is actually adding qualifiers. From nobody Mon Aug 17 09:26: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 9113B1ACE25 for ; Mon, 17 Aug 2015 09:26:40 -0700 (PDT) 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_20=-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 rfDvfN3Rv0NR for ; Mon, 17 Aug 2015 09:26:38 -0700 (PDT) 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 D3BEC1ACE21 for ; Mon, 17 Aug 2015 09:25:59 -0700 (PDT) X-AuditID: 12074425-f799a6d000007db3-82-55d20b16b0bc 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 7A.0C.32179.61B02D55; Mon, 17 Aug 2015 12:25:58 -0400 (EDT) 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 t7HGPwMp023651; Mon, 17 Aug 2015 12:25:58 -0400 Received: from [18.101.8.103] (vpn-18-101-8-103.mit.edu [18.101.8.103]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t7HGPtA2031528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Aug 2015 12:25:57 -0400 Message-ID: <55D20B13.6080105@mit.edu> Date: Mon, 17 Aug 2015 12:25:55 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Benjamin Kaduk , kitten@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEIsWRmVeSWpSXmKPExsUixG6nrivGfSnU4MlaY4ujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY9az46wFO+Qq7l6fx9TAOFWii5GTQ0LAROLIzT5WCFtM4sK9 9WxdjFwcQgKLmSTajqxghXA2Mkocm30BKnOESeJb42RmkBZeATWJM5d2g9ksAqoSUw4sYgGx 2QSUJdbv3wpkc3CICoRJ7NmjClEuKHFy5hOwEhEBY4m7P2+A2cICzhK3Z55hB7GFBBwlvsw+ zQRicwo4STRPeA9WwyygJ7Hj+i9WCFteonnrbOYJjAKzkIydhaRsFpKyBYzMqxhlU3KrdHMT M3OKU5N1i5MT8/JSi3Qt9HIzS/RSU0o3MYKD0kV1B+OEQ0qHGAU4GJV4eC/8vBAqxJpYVlyZ e4hRkoNJSZS3mONSqBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3mg2oBxvSmJlVWpRPkxKmoNF SZx30w++ECGB9MSS1OzU1ILUIpisDAeHkgTvEU6gRsGi1PTUirTMnBKENBMHJ8hwHqDhZ0Bq eIsLEnOLM9Mh8qcYFaXEeU+BJARAEhmleXC9sKTxilEc6BVhXgsuoCoeYMKB634FNJgJaPDh CRdBBpckIqSkGhjDn949VFumxJG/oID/vJlk4873GnfXzJd72y6m2D7jeNFCFbWk0hNpgnNu lCpEvfap2fv/D5fpRDuTOhXdqkXne3ZkmUzfe/CPmJfzKhUu9jfP4x3Z44+Y7rGpWb5gR9xf tY556zROvpGqXFgw5du/tJX6N3yXX9NcEpR/XTA1QFDsQdQLqz1KLMUZiYZazEXFiQDozrYq 9QIAAA== Archived-At: Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01 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, 17 Aug 2015 16:26:40 -0000 In section 2.4, I am confused about this passage: If the freshness token is not valid, the KDC MUST return KDC_ERR_PREAUTH_FAILED with PA_AS_FRESHNESS. Is this saying that the KRB-ERROR message with code KDC_ERR_PREAUTH_FAILED should include e-data containing METHOD-DATA containing a PA-DATA element of type PA_AS_FRESHNESS with a valid freshness token value? If so, it is too abbreviated to be clear. Including METHOD-DATA as e-data for a KDC_ERR_PREAUTH_FAILED is first specified in RFC 6113, so we might need a normative reference to be precise about what's going on. I am also concerned about using KDC_ERR_PREAUTH_FAILED for a retriable error within a preauth mech. When I have reasoned about how the MIT krb5 client preauth framework should be designed (not how it is currently designed), I generally think of PREAUTH_FAILED as indicating that the client should move on to a different preauth mechanism, or retry without optimistic configuration if it was doing optimistic preauth. The prior art for retriable arrors within a mechanism has been to use specific error codes. 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. My remaining comments are editorial. In the abstract: * "PKInit" should be "PKINIT". In the introduction: * There should be a comma after "(ECDH) key agreement". * There should be a comma after "with an encryption key". * There should be a comma after "Section 3.2.1 of [RFC4556]", and possibly the phrase "specified in Section 3.2.1 of [RFC4556]" should be in parentheses. In section 1.1: * The first paragraph is too complicated for one un-punctuated sentence. I suggest: Today, password-based AS exchanges [RFC4120] often begin with the client sending a KRB_AS_REQ message without pre-authentication. The KDC responds with a KRB-ERROR containing information needed to complete an AS exchange, such as the supported encryption types and salt values. This message flow is illustrated below: * The second paragraph is also on the complicated side. I suggest: We can use a similar message flow with PKINIT, allowing the KDC to provide a token for the client to include in its KRB_AS_REQ to ensure that the PA_PK_AS_REQ [RFC4556] was not pre-generated. In section 2: * "KDC provided" should be "KDC-provided". * The clause structure in item 1 is confusing (as witnessed by Ben's reply where he misread it). I suggest: The client generates a KRB_AS_REQ as specified in Section 2.9.3 of [RFC4120], which contains no PA_PK_AS_REQ, and which includes a freshness token request. * In item 4, there should be a comma after "Section 3.2.2 [RFC4556]". In section 2.1: * "PA_AS_FRESHNESS padata type" should be "a padata element with padata-type PA_AS_FRESHNESS and". In section 2.2: * The same substitution as in section 2.1 should be made. In section 2.3: * "PA_DATA" should be "PA-DATA" in both places. In section 2.4: * "implementation specific" should be "implementation-specific". In section 2.5: * This sentence is too complicated. If there are no changes to the behavior here, I recommend: If a client receives a KDC_ERR_PREAUTH_FAILED KRB_ERROR message which includes a PA_AS_FRESHNESS token, it SHOULD generate a new PA_PK_AS_REQ and KRB_AS_REQ using the new freshness token. This scenario may occur if there was too much delay between the client receiving the freshness token and sending its initial PA_PK_AS_REQ message. From nobody Mon Aug 17 09:57: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 5371D1A1A4F for ; Mon, 17 Aug 2015 09:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 7c4pvWzHmRGs for ; Mon, 17 Aug 2015 09:57:17 -0700 (PDT) Received: from edge01.zimbra.com (edge01.zimbra.com [162.209.122.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A8FC1A1A24 for ; Mon, 17 Aug 2015 09:57:17 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by edge01.zimbra.com (Postfix) with ESMTP id CA25744022; Mon, 17 Aug 2015 11:57:16 -0500 (CDT) Received: from edge01.zimbra.com ([127.0.0.1]) by localhost (edge01.zimbra.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id sa4kp_pidSqD; Mon, 17 Aug 2015 11:57:13 -0500 (CDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by edge01.zimbra.com (Postfix) with ESMTP id D2B384402A; Mon, 17 Aug 2015 11:57:13 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.9.3 edge01.zimbra.com D2B384402A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zimbra.com; s=C2AA288C-EE47-11E2-9BB0-E820BDD9BDBF; t=1439830633; bh=BHiBy84EeR015aKShyKXFotzk0rEZYFEi3Yyj8zbsOk=; h=Date:From:To:Message-ID:MIME-Version; b=PcflTC8d5jJLJ+9IXr9k7pThOoMbTLkUGg8mOlHMd7MjZCKgHRUN0Uk3rt7YWe2ZA /RM9vfqy++VsObiG8U+PPu2P22cqR6WhFuJf2k6xbBNNRASbbxL9KAKjlZ8J34n93M szbgI4vHI+pzzsdr7qVl5cDM/34bdALZ0TDcWc9s= X-Virus-Scanned: amavisd-new at edge01.zimbra.com Received: from edge01.zimbra.com ([127.0.0.1]) by localhost (edge01.zimbra.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5xj282zMolaU; Mon, 17 Aug 2015 11:57:13 -0500 (CDT) Received: from [192.168.1.9] (c75-111-52-177.erkacmtk01.ca.dh.suddenlink.net [75.111.52.177]) by edge01.zimbra.com (Postfix) with ESMTPSA id 5C03C44022; Mon, 17 Aug 2015 11:57:13 -0500 (CDT) Date: Mon, 17 Aug 2015 09:57:12 -0700 From: Quanah Gibson-Mount To: Phil Lello Message-ID: <238286CDC59AF99549213CD8@[192.168.1.9]> In-Reply-To: References: <20150812195437.2e03c0c8@latte.josefsson.org> <20150812183657.GG3654@localhost> <6B7C7317-467A-4809-ABA3-FF599332F18D@osu.edu> X-Mailer: Mulberry/4.0.9a1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] [saag] SSH Protocol 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, 17 Aug 2015 16:57:19 -0000 --On Saturday, August 15, 2015 9:52 AM +0100 Phil Lello wrote: > > > > Thanks to everyone for their input. I think my efforts would be better > directed at extending the SSH protocol to support SASL; although SASL/GSS > binding (RFC5801) is possible in some cases, it isn't always. > > Is there an industry standard for SASL in C? I'm aware of > https://tools.ietf.org/html/draft-newman-sasl-c-api-03 from April 2004 > and the GSASL http://www.gnu.org/software/gsasl/ library, but am looking > for a standard mechanism where adding new SASL mechanisms is a case of > adding a run-time plugin (.so / .dll). --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From nobody Mon Aug 17 14:19: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 363621A7017 for ; Mon, 17 Aug 2015 14:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kNPw1lugRNFH for ; Mon, 17 Aug 2015 14:19:41 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0128.outbound.protection.outlook.com [207.46.100.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD0991A7012 for ; Mon, 17 Aug 2015 14:19:40 -0700 (PDT) Received: from BL2PR03MB212.namprd03.prod.outlook.com (10.255.230.151) by BL2PR03MB210.namprd03.prod.outlook.com (10.255.230.144) with Microsoft SMTP Server (TLS) id 15.1.231.11; Mon, 17 Aug 2015 21:19:38 +0000 Received: from BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.53]) by BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.53]) with mapi id 15.01.0231.011; Mon, 17 Aug 2015 21:19:18 +0000 From: Michiko Short To: "kitten@ietf.org" Thread-Topic: WGLC on draft-ietf-kitten-pkinit-freshness-01 Thread-Index: AdDZMl8FN1C3M9OvTA6srdSg4s7CMQ== Date: Mon, 17 Aug 2015 21:19:17 +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:3::7ac] x-microsoft-exchange-diagnostics: 1; BL2PR03MB210; 5:AsMd6tWNLmGBXLCFzJQXo0AjQKjiFogCTaBeycobk8+xE+7O3wU0UFMYSF9ADzyLbdw6HfSumJ0kVFrvkx4hO/zLe/aL3ubh2TovRTmPYYfiB26+b1UJOKz6QPPkcDmAcF8ljGNhWT+DOGBFcrl4JQ==; 24:2cF/vVHNcJHWAJfkelmCZJ03dMxpHkochnMaBYlp2rl1xdPZqQsjADfe5wwSUWqD6oCz6SirIi8G34T9arKCvjm1WtuDGT2v6aThxe9+Y4k=; 20:AND681qV71a4nUBcPFnsaI+SmaiNNdbdpP7RnwCGAeGw4E2J9BUKy0BmUxjEyrajH3apS9b2pvtZrbcpoqfHAQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB210; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(8121501046)(3002001); SRVR:BL2PR03MB210; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB210; x-forefront-prvs: 0671F32598 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(24454002)(13464003)(86612001)(107886002)(2351001)(81156007)(110136002)(50986999)(5003600100002)(4001540100001)(64706001)(106356001)(76576001)(33656002)(10090500001)(230783001)(10290500002)(2501003)(5005710100001)(10400500002)(8990500004)(5001860100001)(5001920100001)(105586002)(5001960100002)(19580405001)(87936001)(97736004)(122556002)(19580395003)(46102003)(99286002)(86362001)(450100001)(5002640100001)(189998001)(62966003)(102836002)(5001830100001)(92566002)(74316001)(68736005)(15975445007)(101416001)(54356999)(2900100001)(77156002)(2656002)(40100003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB210; H:BL2PR03MB212.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: 17 Aug 2015 21:19:17.6336 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB210 Archived-At: Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01 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, 17 Aug 2015 21:19:43 -0000 How about: 1. The client generates a KRB_AS_REQ as specified in Section 2.9.3 [RFC4120] without an authenticator that requests a freshness token. -----Original Message----- Message: 3 Date: Sun, 16 Aug 2015 11:31:46 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01 Message-ID: Content-Type: TEXT/PLAIN; charset=3DUS-ASCII On Sun, 16 Aug 2015, Benjamin Kaduk wrote: > This message begins the Working Group Last Call (WGLC) of "Public Key=20 > Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness=20 > Extension" . The WGLC will last=20 > two weeks, ending on Sunday, August 30th. The draft is available at: > > https://tools.ietf.org/html/draft-ietf-kitten-pkinit-freshness-01 One minor thing occurred to me while I was reading through prior to startin= g the WGLC: in section 2, bullet 1, the current text has "without an authen= ticator which includes the freshness token request to the KDC", which doesn= 't seem quite right -- this un-preauthenticated AS-REQ does not have a fres= hness token included in it, but it is intended to request a freshness token= from the KDC. So, it might be better to just say "without an authenticato= r that includes a freshness token" [0]. (It would not be correct to say "w= ith an authenticator that does not include a freshness token", right?) -Ben [0] The RFC Editor would change "which" to "that", since their criterion is= that "which" is used when clarifying a property of all occurrences of the = class being described, whereas "that" is used when the additional clause is= actually adding qualifiers. ------------------------------ Subject: Digest Footer _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten ------------------------------ End of Kitten Digest, Vol 129, Issue 5 ************************************** From nobody Mon Aug 17 14:35: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 1F8081A885A for ; Mon, 17 Aug 2015 14:35:30 -0700 (PDT) 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 pCsf5PNjU2Ii for ; Mon, 17 Aug 2015 14:35:28 -0700 (PDT) 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 92CF11A882C for ; Mon, 17 Aug 2015 14:35:28 -0700 (PDT) X-AuditID: 12074423-f79496d000001e58-a9-55d2539fc627 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 A5.7E.07768.F9352D55; Mon, 17 Aug 2015 17:35:27 -0400 (EDT) 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 t7HLZQDl030383; Mon, 17 Aug 2015 17:35:27 -0400 Received: from [18.101.8.103] (vpn-18-101-8-103.mit.edu [18.101.8.103]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t7HLZORA027130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Aug 2015 17:35:26 -0400 Message-ID: <55D2539C.6080506@mit.edu> Date: Mon, 17 Aug 2015 17:35:24 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Michiko Short , "kitten@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixG6nojs/+FKoQUubgsXRzatYLP518zkw eSxZ8pPJo3XHX/YApigum5TUnMyy1CJ9uwSujJWzuxkLWlgq5i5tZG5gnMXcxcjJISFgInHh /Q1WCFtM4sK99WxdjFwcQgKLmSR69qxlh3A2Mkq03Z8J5RxhkjhydAJYC6+AmkRr0wUwm0VA VeLM2seMIDabgLLE+v1bWboYOThEBcIk9uxRhSgXlDg58wlYWEQgQmJuayxIWFjAWeL2zDPs ILaQQJTE8WOtYBM5BaIlTv78zARiMwvoSey4/osVwpaX2P52DvMERoFZSKbOQlI2C0nZAkbm VYyyKblVurmJmTnFqcm6xcmJeXmpRbpmermZJXqpKaWbGMFB6qK8g/HPQaVDjAIcjEo8vBd+ XggVYk0sK67MPcQoycGkJMprqHEpVIgvKT+lMiOxOCO+qDQntfgQowQHs5IIbywXUI43JbGy KrUoHyYlzcGiJM676QdfiJBAemJJanZqakFqEUxWhoNDSYJ3fRBQo2BRanpqRVpmTglCmomD E2Q4D9Dwd4Egw4sLEnOLM9Mh8qcYdTkW/Li9lkmIJS8/L1VKnDcHZJAASFFGaR7cHFhyecUo DvSWMG8tSBUPMDHBTXoFtIQJaMnhCRdBlpQkIqSkGhidv7NUfXd5dEuzkdVXYv11ni271NKE krXvB11+Hy/Hdy8g5p7oA+uf77NSz+nvP9qmu+9jFPv22p1pPw/tM+ys7veuzPThZwwvLjE+ 9PZX44uSPg+mmDbjDyJmK24t3DaZxXIKz64jK2Rl65rEU47HT9rtIBrV9VPmn/pi9QWrMo6K /Y5hWq3EUpyRaKjFXFScCAC84RlACQMAAA== Archived-At: Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01 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, 17 Aug 2015 21:35:30 -0000 On 08/17/2015 05:19 PM, Michiko Short wrote: > 1. The client generates a KRB_AS_REQ as specified in Section 2.9.3 > [RFC4120] without an authenticator that requests a freshness > token. Just to make sure: the intent of the text is that the initial KRB_AS_REQ does not include PA_PK_AS_REQ pa-data, but does include PA_AS_FRESHNESS pa-data requesting a freshness token. The suggested clarification do not convey this intent. I suggested a different clarification in my longer response. From nobody Thu Aug 20 11:42: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 E7F841A8739 for ; Thu, 20 Aug 2015 11:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 F20o9yxqUU70 for ; Thu, 20 Aug 2015 11:42:42 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0120.outbound.protection.outlook.com [207.46.100.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8311B1AD0C4 for ; Thu, 20 Aug 2015 11:42:42 -0700 (PDT) Received: from BL2PR03MB212.namprd03.prod.outlook.com (10.255.230.151) by BL2PR03MB212.namprd03.prod.outlook.com (10.255.230.151) with Microsoft SMTP Server (TLS) id 15.1.231.11; Thu, 20 Aug 2015 18:42:41 +0000 Received: from BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.53]) by BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.53]) with mapi id 15.01.0231.011; Thu, 20 Aug 2015 18:42:41 +0000 From: Michiko Short To: Greg Hudson , "kitten@ietf.org" Thread-Topic: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01 Thread-Index: AdDZMl8FN1C3M9OvTA6srdSg4s7CMQAAkEAAAJCghqA= Date: Thu, 20 Aug 2015 18:42:41 +0000 Message-ID: References: <55D2539C.6080506@mit.edu> In-Reply-To: <55D2539C.6080506@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=michikos@microsoft.com; x-originating-ip: [2001:4898:80e8::2c4] x-microsoft-exchange-diagnostics: 1; BL2PR03MB212; 5:GKkM2Kx7msRmD0WvO07gYYlbtqABcidKmXyd2fxlosjKgERECJnjartJEmFAST1q3zIxhfcv0l8dZ3nrRZHGA7mYyD+MzLnHF36GuW29TMTAml4rF1glpeL9wwmca2vg0fkruDTP7QLitADbeY/mmw==; 24:4cZT3NZvXX+aHuWCr4G1nbY4hagQPp338JHeAUXZ9/vSIA+uda/WYS5LQwuJSq1ihkdPrvrHSA9GsDVoUcaBl0JAtxT/M5NpnIIeL1U7yL4=; 20:yKogHhiNm5xC8pIwgPO9AHY3IgxE5AV2yNPP0LdVfsGMe6oBoAqblSlhdShj5wP3xwNZGBauZCQKhDvrdAzrZQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB212; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(8121501046)(3002001); SRVR:BL2PR03MB212; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB212; x-forefront-prvs: 0674DC6DD3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(479174004)(189002)(24454002)(199003)(377454003)(101416001)(74316001)(189998001)(77156002)(5003600100002)(4001540100001)(2900100001)(40100003)(5001830100001)(2171001)(46102003)(5001860100001)(86362001)(107886002)(97736004)(2950100001)(122556002)(5001770100001)(5001960100002)(64706001)(5004730100002)(62966003)(10090500001)(76576001)(81156007)(102836002)(2501003)(105586002)(50986999)(5005710100001)(8990500004)(106356001)(68736005)(86612001)(99286002)(54356999)(76176999)(92566002)(33656002)(87936001)(2656002)(19580395003)(19580405001)(5002640100001)(10400500002)(10290500002)(5007970100001)(230783001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB212; H:BL2PR03MB212.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: 20 Aug 2015 18:42:41.6898 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB212 Archived-At: Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01 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, 20 Aug 2015 18:42:44 -0000 I saw that. Appreciated your long, complete feedback. Have done a quick loo= k and the only significant change I saw was the error.=20 -----Original Message----- From: Greg Hudson [mailto:ghudson@mit.edu]=20 Sent: Monday, August 17, 2015 2:35 PM To: Michiko Short ; kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01 On 08/17/2015 05:19 PM, Michiko Short wrote: > 1. The client generates a KRB_AS_REQ as specified in Section 2.9.3 > [RFC4120] without an authenticator that requests a freshness > token. Just to make sure: the intent of the text is that the initial KRB_AS_REQ do= es not include PA_PK_AS_REQ pa-data, but does include PA_AS_FRESHNESS pa-da= ta requesting a freshness token. The suggested clarification do not convey= this intent. I suggested a different clarification in my longer response. From nobody Tue Aug 25 08:57:48 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 4315F1B3114 for ; Tue, 25 Aug 2015 08:57:46 -0700 (PDT) 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 jNN40wvG5ufW for ; Tue, 25 Aug 2015 08:57:43 -0700 (PDT) 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 60FBB1B2F5D for ; Tue, 25 Aug 2015 08:57:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 18CCCBE55; Tue, 25 Aug 2015 16:57:38 +0100 (IST) 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 CXT7uODX1Y_6; Tue, 25 Aug 2015 16:57:37 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D6ED0BE33; Tue, 25 Aug 2015 16:57:37 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1440518257; bh=1VWeCLa8ApwbVrBPvsKt4MfMc7Fo1sUhNlYIzSOTHfA=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=PBjC5cESyXCKnYsr3VLIjdLJf/mekMneCSOGfOMlgUd7/XTHEim6CRSZ6inMOQzen EPc4BgE+ZudD1iYB/GQTCn0cc/r7P5dMLS0NssZEzXb4IA3+WYmeQ385XrNyUEw/sH T4kCuJwStFRW2AzZyMZDv+tBYkHU0z2d7RaFRo98= Message-ID: <55DC9070.5020302@cs.tcd.ie> Date: Tue, 25 Aug 2015 16:57:36 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Tony Hansen , Alexey Melnikov References: <20150720084611.5447.46804.idtracker@ietfa.amsl.com> <55ACB747.5050006@att.com> <871tg239px.fsf@latte.josefsson.org> <55B4E1D0.7000108@isode.com> <55B78429.2060408@att.com> <55B78838.2020808@isode.com> <87io94vwht.fsf@latte.josefsson.org> <55B7F002.3040308@att.com> In-Reply-To: <55B7F002.3040308@att.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="i24kokSpxMt2R0q8eTN6w94GdfWA1asl6" Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-hansen-scram-sha256-03.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, 25 Aug 2015 15:57:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --i24kokSpxMt2R0q8eTN6w94GdfWA1asl6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Tony, all, The 2nd IETF last call for this is done. This thread is I think the only thing that needs to be processed. (Please correct me if I'm wrong.) Tony - will you please make the changes described below and submit a -04 with those in? (Feel free to check with folks beforehand as to precise wording.) If you can get that done in the couple of days I'll be happy to put this on the Sep 3rd IESG telechat for approval. If it takes longer (but pretty please, not so long this time:-) then it'll slip. Cheers, S. On 28/07/15 22:11, Tony Hansen wrote: > I'll work something in along these lines. Thanks for continuing to bang= > on this. >=20 > Tony >=20 > On 7/28/15 4:49 PM, Simon Josefsson wrote: >> Alexey Melnikov writes: >> >>> Hi Tony, >>> >>> On 28/07/2015 14:31, Tony Hansen wrote: >>>> I will add this text to the security considerations section. >>>> >>>> This doc >is< updating RFC 5802 (the base SCRAM spec), so what do yo= u >>>> think of stating that this also applies to scram-sha-1? >>> I am Ok with that. Although I suspect that most implementors are not >>> going to look for this advice in your document. >> I agree, so there is a problem. To adress it, can we make the abstrac= t >> and introduction of scram-sha256 say that the document is ALSO adressi= ng >> a security problem in the base RFC 5802 specification? Perhaps going = as >> far as modifying the title. To me, this normative language related to= >> TLS-SESSION-HASH have importance to RFC 5802 implementers. >> >> How about modifying the abstract from: >> >> This document registers the SASL mechanisms SCRAM-SHA-256 and SCRAM= - >> SHA-256-PLUS. It also updates the SCRAM registration procedures of= >> RFC 5802. >> >> into >> >> This document registers the SASL mechanisms SCRAM-SHA-256 and SCRAM= - >> SHA-256-PLUS, and provide guidance for secure implementation of the= >> original SCRAM-SHA-1-PLUS mechanism. It also updates the SCRAM >> registration procedures of RFC 5802. >> >> And add to the Introduction section the following paragraph: >> >> After publication of RFC 5802, it was discovered that TLS does not >> have the expected properties for the tls-unique channel binding to b= e >> secure [TLS-SESSION-HASH]. Therefor, this document contain normativ= e >> text that applies to both the original SCRAM-SHA-1-PLUS and the newl= y >> introduced SCRAM-SHA-256-PLUS mechanism. >> >> I can't help but finish this repeating my rant that I don't think any = of >> this will be effective, and that we will face a long time of insecure >> SCRAM-PLUS adoption. Application writers in general cannot sufficient= ly >> guarantee that their TLS stack always uses TLS-SESSION-HASH. Alas, it= >> seems this approach is the most likely to reach consensus, and that >> stalling this document further is not productive. >> >> /Simon >> >>>> Tony >>>> >>>> On 7/26/15 9:34 AM, Alexey Melnikov wrote: >>>>> On 20/07/2015 20:33, Simon Josefsson wrote: >>>>>> Tony Hansen writes: >>>>>> >>>>>>> Note: I have NOT done anything about incorporating session >>>>>>> hashing for channel binding, as I remain unconvinced that this is= >>>>>>> the right document to do anything about the topic. If you feel >>>>>>> otherwise about having >this document< mention something about >>>>>>> channel binding, >please< suggest specific text. >>>>>> You may use: >>>>>> >>>>>> To be secure, SCRAM-SHA-256-PLUS has to be used over a TLS channel= >>>>>> that MUST have [TLS-SESSION-HASH] negotiated, or session resumptio= n >>>>>> MUST NOT have been used. >>>>>> >>>>>> [TLS-SESSION-HASH] >>>>>> https://tools.ietf.org/html/draft-ietf-tls-session-hash-06 >>>>>> >>>>>> If this (or some other text) is not added, we would publish a >>>>>> known insecure protocol without any discussion of the problem. >>>>> I agree that this should be added. While the preferred way would be= to >>>>> update the base SCRAM specification, I think this note is still >>>>> preferable to saying nothing. >>>>> >>>>> >=20 >=20 >=20 >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten >=20 --i24kokSpxMt2R0q8eTN6w94GdfWA1asl6 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 iQEcBAEBCAAGBQJV3JBxAAoJEC88hzaAX42iDYEIAKNwm12U3Kbwq3r+icDEIiz2 Di5UrUzT8wFmJg0dedjgmaNC19ckmsrdgobRA93GnlaANqRsxeBTn+UVZGdn2Ion Xws3ZKI6mW7UTGHSv420LrwDzbIn7iVgbgdN8BGIwrVTeRlrQX4nMfaMZQ4jHzJJ /8r5OUl9UXZ1oCzMRy1kfiGn1zDOXIra28Lt3Hz9i+hvB/NZVtH2g59v/DPmP4Tg KR3QsP5YSJDQjnF7898o1BRhpEddG4zb/3cA9NjsyBf59aGfSk/YS9WbKzEgZlGp dsbYhNRKVOe4ZcFAH3o9U6chssJM9aGpJWHB4TOaPizdoumbhtqJbqHtnwt1c8Y= =G3pG -----END PGP SIGNATURE----- --i24kokSpxMt2R0q8eTN6w94GdfWA1asl6-- From nobody Tue Aug 25 11:08:55 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 BBBBA1A873B for ; Tue, 25 Aug 2015 11:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ARk6_MwK6yTP for ; Tue, 25 Aug 2015 11:08:52 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 E9F181A86FF for ; Tue, 25 Aug 2015 11:08:51 -0700 (PDT) Received: from pps.filterd (m0049292.ppops.net [127.0.0.1]) by m0049292.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t7PI8gCS008435 for ; Tue, 25 Aug 2015 14:08:51 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049292.ppops.net-00191d01. with ESMTP id 1wg68kn032-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 25 Aug 2015 14:08:51 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t7PI8ots023049 for ; Tue, 25 Aug 2015 14:08:50 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t7PI8hHo022988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 25 Aug 2015 14:08:43 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi132.aldc.att.com (RSA Interceptor) for ; Tue, 25 Aug 2015 18:08:34 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t7PI8YPB016065 for ; Tue, 25 Aug 2015 14:08:34 -0400 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t7PI8QQY015565 for ; Tue, 25 Aug 2015 14:08:27 -0400 Received: from cacdtl01ea6628.itservices.sbc.com (cacdtl01ea6628.itservices.sbc.com?[135.110.241.53](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150825180825gw1000ce5le>; Tue, 25 Aug 2015 18:08:26 +0000 X-Originating-IP: [135.110.241.53] To: Stephen Farrell , Alexey Melnikov References: <20150720084611.5447.46804.idtracker@ietfa.amsl.com> <55ACB747.5050006@att.com> <871tg239px.fsf@latte.josefsson.org> <55B4E1D0.7000108@isode.com> <55B78429.2060408@att.com> <55B78838.2020808@isode.com> <87io94vwht.fsf@latte.josefsson.org> <55B7F002.3040308@att.com> <55DC9070.5020302@cs.tcd.ie> From: Tony Hansen Message-ID: <55DCAF17.6040309@att.com> Date: Tue, 25 Aug 2015 14:08:23 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55DC9070.5020302@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ivPuaoLHoeCHAWI2iJih7NsvdXuL4oSUa" X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-08-25_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1508250259 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-hansen-scram-sha256-03.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, 25 Aug 2015 18:08:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ivPuaoLHoeCHAWI2iJih7NsvdXuL4oSUa Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Stephen, I actually had an update almost complete, waiting for the LC to finish. :-) I've just submitted a -04. I feel that it addresses everything asked for during LC. In particular, Simon, I hope the additions provide everything you think is needed. Diff can be found at . Tony On 8/25/15 11:57 AM, Stephen Farrell wrote: > Hi Tony, all, > > The 2nd IETF last call for this is done. This thread is I think > the only thing that needs to be processed. (Please correct me if > I'm wrong.) > > Tony - will you please make the changes described below and > submit a -04 with those in? (Feel free to check with folks beforehand > as to precise wording.) > > If you can get that done in the couple of days I'll be happy to put > this on the Sep 3rd IESG telechat for approval. If it takes longer > (but pretty please, not so long this time:-) then it'll slip. > > Cheers, > S. > > > > On 28/07/15 22:11, Tony Hansen wrote: >> I'll work something in along these lines. Thanks for continuing to ban= g >> on this. >> >> Tony >> >> On 7/28/15 4:49 PM, Simon Josefsson wrote: >>> Alexey Melnikov writes: >>> >>>> Hi Tony, >>>> >>>> On 28/07/2015 14:31, Tony Hansen wrote: >>>>> I will add this text to the security considerations section. >>>>> >>>>> This doc >is< updating RFC 5802 (the base SCRAM spec), so what do y= ou >>>>> think of stating that this also applies to scram-sha-1? >>>> I am Ok with that. Although I suspect that most implementors are not= >>>> going to look for this advice in your document. >>> I agree, so there is a problem. To adress it, can we make the abstra= ct >>> and introduction of scram-sha256 say that the document is ALSO adress= ing >>> a security problem in the base RFC 5802 specification? Perhaps going= as >>> far as modifying the title. To me, this normative language related t= o >>> TLS-SESSION-HASH have importance to RFC 5802 implementers. >>> >>> How about modifying the abstract from: >>> >>> This document registers the SASL mechanisms SCRAM-SHA-256 and SCRA= M- >>> SHA-256-PLUS. It also updates the SCRAM registration procedures o= f >>> RFC 5802. >>> >>> into >>> >>> This document registers the SASL mechanisms SCRAM-SHA-256 and SCRA= M- >>> SHA-256-PLUS, and provide guidance for secure implementation of th= e >>> original SCRAM-SHA-1-PLUS mechanism. It also updates the SCRAM >>> registration procedures of RFC 5802. >>> >>> And add to the Introduction section the following paragraph: >>> >>> After publication of RFC 5802, it was discovered that TLS does not >>> have the expected properties for the tls-unique channel binding to = be >>> secure [TLS-SESSION-HASH]. Therefor, this document contain normati= ve >>> text that applies to both the original SCRAM-SHA-1-PLUS and the new= ly >>> introduced SCRAM-SHA-256-PLUS mechanism. >>> >>> I can't help but finish this repeating my rant that I don't think any= of >>> this will be effective, and that we will face a long time of insecure= >>> SCRAM-PLUS adoption. Application writers in general cannot sufficien= tly >>> guarantee that their TLS stack always uses TLS-SESSION-HASH. Alas, i= t >>> seems this approach is the most likely to reach consensus, and that >>> stalling this document further is not productive. >>> >>> /Simon >>> >>>>> Tony >>>>> >>>>> On 7/26/15 9:34 AM, Alexey Melnikov wrote: >>>>>> On 20/07/2015 20:33, Simon Josefsson wrote: >>>>>>> Tony Hansen writes: >>>>>>> >>>>>>>> Note: I have NOT done anything about incorporating session >>>>>>>> hashing for channel binding, as I remain unconvinced that this i= s >>>>>>>> the right document to do anything about the topic. If you feel >>>>>>>> otherwise about having >this document< mention something about >>>>>>>> channel binding, >please< suggest specific text. >>>>>>> You may use: >>>>>>> >>>>>>> To be secure, SCRAM-SHA-256-PLUS has to be used over a TLS channe= l >>>>>>> that MUST have [TLS-SESSION-HASH] negotiated, or session resumpti= on >>>>>>> MUST NOT have been used. >>>>>>> >>>>>>> [TLS-SESSION-HASH] >>>>>>> https://tools.ietf.org/html/draft-ietf-tls-session-hash-06 >>>>>>> >>>>>>> If this (or some other text) is not added, we would publish a >>>>>>> known insecure protocol without any discussion of the problem. >>>>>> I agree that this should be added. While the preferred way would b= e to >>>>>> update the base SCRAM specification, I think this note is still >>>>>> preferable to saying nothing. >>>>>> >>>>>> >> >> >> >> _______________________________________________ >> Kitten mailing list >> Kitten@ietf.org >> https://www.ietf.org/mailman/listinfo/kitten >> --ivPuaoLHoeCHAWI2iJih7NsvdXuL4oSUa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJV3K8YAAoJEKd93u989/Ut/K0QAKn90hEg6GbTKJ6YFCzwcic8 bDauPRRUrDdn5OkLDrsoeKhQ/jqbGDUCAzo6hEFjTd/JcNgwqkNYYSl4TnusWU+W ZzcO5H+JkMwA+BdEK5QqFP7fZMK2SuNdwSOyuqJSxtetePKTfF8T4r00BB+ClviT wL3SNUkHPfa8/M443DI2vbCCaW5ypCmZiTLqsEFaBwnle+q37BnCuriVsG9Hg5hT TxpNkS8tWmckwV63Q688JISiisQe64I5nehgk25pPkFMQjj6wbRRunsH3asT5GAo 8MyEDkK9MZuAD5jiKRRk7CzWAjvy+3HkByMn/LMW8c3/rnY8O25z1nGq0+uWgqhG fKN2bs5kPvCK2zwKhiskVyoyHgkGDz+J1qZLqi6PpJWS51jsal0RGeCN0HMDVf4o 91VWnFzMS1JteFB4DwiHmr59nIa95qBWWctZjmuW4ihlrVK4u4C3h8GT9vG/rsBH KtooD+MdapX9Ju1RI3bHIIvb8za56Mr+ewyJJ5TKUl5Cs+i8Q7yNn+3s2H8F8c6e 8v/A39QrwkQUPavgw4oiPReHXqNOfOZ1r8YngfKry9I2SPu36i9JCn1K35RyB2E/ PmmYJApSLJ9F4BAJVrx7E/Lwzu4IRREQpbe1FJACw79bplXS9iuMC2XZEYqMXVll mtcKpVoMjW0yjGj4UKH7 =Ogtl -----END PGP SIGNATURE----- --ivPuaoLHoeCHAWI2iJih7NsvdXuL4oSUa-- From nobody Tue Aug 25 11:42: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 CEAF01A871A for ; Tue, 25 Aug 2015 11:42:28 -0700 (PDT) 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 TIUwicTW1PEa for ; Tue, 25 Aug 2015 11:42:26 -0700 (PDT) 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 EE8B61A044D for ; Tue, 25 Aug 2015 11:42:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D94F2BE39; Tue, 25 Aug 2015 19:42:23 +0100 (IST) 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 yl1NIv5RDx2h; Tue, 25 Aug 2015 19:42:21 +0100 (IST) Received: from [127.0.0.1] (unknown [86.46.21.200]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7CB75BE64; Tue, 25 Aug 2015 19:42:21 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1440528141; bh=blwR5vvxY455XCFO3ByUg7DlR1+DPeH2t+wq6m4jhbE=; h=To:Cc:From:Subject:In-Reply-To:References:Date:From; b=gN4eM1eza8K2V/zzQqPAHOgYejm/uEwL7WGa4IkmtTsn+a6RY67DQRYqUDnJszXJ6 +Sqy6q2kqmRXQ0d8SmUiqW7n7SRcuRxIFUcZKRNiUN0gWZxLH2IPT8OEaKMXR/zHVR /F8QFi3FLrgbVFGbxNXg8s1GZeakc+DnxzNIUEGo= X-Priority: 3 To: tony@att.com From: stephen.farrell@cs.tcd.ie In-Reply-To: <55DCAF17.6040309@att.com> References: <20150720084611.5447.46804.idtracker@ietfa.amsl.com> <55ACB747.5050006@att.com> <871tg239px.fsf@latte.josefsson.org> <55B4E1D0.7000108@isode.com> <55B78429.2060408@att.com> <55B78838.2020808@isode.com> <87io94vwht.fsf@latte.josefsson.org> <55B7F002.3040308@att.com> <55DC9070.5020302@cs.tcd.ie> <55DCAF17.6040309@att.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Date: Tue, 25 Aug 2015 18:42:19 +0000 Message-ID: MIME-Version: 1.0 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-hansen-scram-sha256-03.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, 25 Aug 2015 18:42:29 -0000 DQoNCk9uIFR1ZSBBdWcgMjUgMTk6MDg6MjMgMjAxNSBHTVQrMDEwMCwgVG9ueSBIYW5zZW4gd3Jv dGU6DQo+IFN0ZXBoZW4sIEkgYWN0dWFsbHkgaGFkIGFuIHVwZGF0ZSBhbG1vc3QgY29tcGxldGUs IHdhaXRpbmcgZm9yIHRoZSBMQyB0bw0KPiBmaW5pc2guIDotKQ0KDQpGYW50YXN0aWMsIEknbGwg bG9vayBhdCBpdCBsYXRlciBhbmQgcHVzaCBpdCBhbG9uZy4NCg0KUy4NCg0KDQo+IA0KPiBJJ3Zl IGp1c3Qgc3VibWl0dGVkIGEgLTA0LiBJIGZlZWwgdGhhdCBpdCBhZGRyZXNzZXMgZXZlcnl0aGlu ZyBhc2tlZCBmb3INCj4gZHVyaW5nIExDLiBJbiBwYXJ0aWN1bGFyLCBTaW1vbiwgSSBob3BlIHRo ZSBhZGRpdGlvbnMgcHJvdmlkZSBldmVyeXRoaW5nDQo+IHlvdSB0aGluayBpcyBuZWVkZWQuDQo+ IA0KPiBEaWZmIGNhbiBiZSBmb3VuZCBhdA0KPiA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWhhbnNlbi1zY3JhbS1zaGEyNTYtMDQ+Lg0KPiANCj4gICAgIFRvbnkNCj4g DQo+IE9uIDgvMjUvMTUgMTE6NTcgQU0sIFN0ZXBoZW4gRmFycmVsbCB3cm90ZToNCj4gPiBIaSBU b255LCBhbGwsDQo+ID4NCj4gPiBUaGUgMm5kIElFVEYgbGFzdCBjYWxsIGZvciB0aGlzIGlzIGRv bmUuIFRoaXMgdGhyZWFkIGlzIEkgdGhpbmsNCj4gPiB0aGUgb25seSB0aGluZyB0aGF0IG5lZWRz IHRvIGJlIHByb2Nlc3NlZC4gKFBsZWFzZSBjb3JyZWN0IG1lIGlmDQo+ID4gSSdtIHdyb25nLikN Cj4gPg0KPiA+IFRvbnkgLSB3aWxsIHlvdSBwbGVhc2UgbWFrZSB0aGUgY2hhbmdlcyBkZXNjcmli ZWQgYmVsb3cgYW5kDQo+ID4gc3VibWl0IGEgLTA0IHdpdGggdGhvc2UgaW4/IChGZWVsIGZyZWUg dG8gY2hlY2sgd2l0aCBmb2xrcyBiZWZvcmVoYW5kDQo+ID4gYXMgdG8gcHJlY2lzZSB3b3JkaW5n LikNCj4gPg0KPiA+IElmIHlvdSBjYW4gZ2V0IHRoYXQgZG9uZSBpbiB0aGUgY291cGxlIG9mIGRh eXMgSSdsbCBiZSBoYXBweSB0byBwdXQNCj4gPiB0aGlzIG9uIHRoZSBTZXAgM3JkIElFU0cgdGVs ZWNoYXQgZm9yIGFwcHJvdmFsLiBJZiBpdCB0YWtlcyBsb25nZXINCj4gPiAoYnV0IHByZXR0eSBw bGVhc2UsIG5vdCBzbyBsb25nIHRoaXMgdGltZTotKSB0aGVuIGl0J2xsIHNsaXAuDQo+ID4NCj4g PiBDaGVlcnMsDQo+ID4gUy4NCj4gPg0KPiA+DQo+ID4NCj4gPiBPbiAyOC8wNy8xNSAyMjoxMSwg VG9ueSBIYW5zZW4gd3JvdGU6DQo+ID4+IEknbGwgd29yayBzb21ldGhpbmcgaW4gYWxvbmcgdGhl c2UgbGluZXMuIFRoYW5rcyBmb3IgY29udGludWluZyB0byBiYW5nDQo+ID4+IG9uIHRoaXMuDQo+ ID4+DQo+ID4+ICAgICBUb255DQo+ID4+DQo+ID4+IE9uIDcvMjgvMTUgNDo0OSBQTSwgU2ltb24g Sm9zZWZzc29uIHdyb3RlOg0KPiA+Pj4gQWxleGV5IE1lbG5pa292IDxhbGV4ZXkubWVsbmlrb3ZA aXNvZGUuY29tPiB3cml0ZXM6DQo+ID4+Pg0KPiA+Pj4+IEhpIFRvbnksDQo+ID4+Pj4NCj4gPj4+ PiBPbiAyOC8wNy8yMDE1IDE0OjMxLCBUb255IEhhbnNlbiB3cm90ZToNCj4gPj4+Pj4gSSB3aWxs IGFkZCB0aGlzIHRleHQgdG8gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24uDQo+ ID4+Pj4+DQo+ID4+Pj4+IFRoaXMgZG9jID5pczwgdXBkYXRpbmcgUkZDIDU4MDIgKHRoZSBiYXNl IFNDUkFNIHNwZWMpLCBzbyB3aGF0IGRvIHlvdQ0KPiA+Pj4+PiB0aGluayBvZiBzdGF0aW5nIHRo YXQgdGhpcyBhbHNvIGFwcGxpZXMgdG8gc2NyYW0tc2hhLTE/DQo+ID4+Pj4gSSBhbSBPayB3aXRo IHRoYXQuIEFsdGhvdWdoIEkgc3VzcGVjdCB0aGF0IG1vc3QgaW1wbGVtZW50b3JzIGFyZSBub3QN Cj4gPj4+PiBnb2luZyB0byBsb29rIGZvciB0aGlzIGFkdmljZSBpbiB5b3VyIGRvY3VtZW50Lg0K PiA+Pj4gSSBhZ3JlZSwgc28gdGhlcmUgaXMgYSBwcm9ibGVtLiAgVG8gYWRyZXNzIGl0LCBjYW4g d2UgbWFrZSB0aGUgYWJzdHJhY3QNCj4gPj4+IGFuZCBpbnRyb2R1Y3Rpb24gb2Ygc2NyYW0tc2hh MjU2IHNheSB0aGF0IHRoZSBkb2N1bWVudCBpcyBBTFNPIGFkcmVzc2luZw0KPiA+Pj4gYSBzZWN1 cml0eSBwcm9ibGVtIGluIHRoZSBiYXNlIFJGQyA1ODAyIHNwZWNpZmljYXRpb24/ICBQZXJoYXBz IGdvaW5nIGFzDQo+ID4+PiBmYXIgYXMgbW9kaWZ5aW5nIHRoZSB0aXRsZS4gIFRvIG1lLCB0aGlz IG5vcm1hdGl2ZSBsYW5ndWFnZSByZWxhdGVkIHRvDQo+ID4+PiBUTFMtU0VTU0lPTi1IQVNIIGhh dmUgaW1wb3J0YW5jZSB0byBSRkMgNTgwMiBpbXBsZW1lbnRlcnMuDQo+ID4+Pg0KPiA+Pj4gSG93 IGFib3V0IG1vZGlmeWluZyB0aGUgYWJzdHJhY3QgZnJvbToNCj4gPj4+DQo+ID4+PiAgICBUaGlz IGRvY3VtZW50IHJlZ2lzdGVycyB0aGUgU0FTTCBtZWNoYW5pc21zIFNDUkFNLVNIQS0yNTYgYW5k IFNDUkFNLQ0KPiA+Pj4gICAgU0hBLTI1Ni1QTFVTLiAgSXQgYWxzbyB1cGRhdGVzIHRoZSBTQ1JB TSByZWdpc3RyYXRpb24gcHJvY2VkdXJlcyBvZg0KPiA+Pj4gICAgUkZDIDU4MDIuDQo+ID4+Pg0K PiA+Pj4gaW50bw0KPiA+Pj4NCj4gPj4+ICAgIFRoaXMgZG9jdW1lbnQgcmVnaXN0ZXJzIHRoZSBT QVNMIG1lY2hhbmlzbXMgU0NSQU0tU0hBLTI1NiBhbmQgU0NSQU0tDQo+ID4+PiAgICBTSEEtMjU2 LVBMVVMsIGFuZCBwcm92aWRlIGd1aWRhbmNlIGZvciBzZWN1cmUgaW1wbGVtZW50YXRpb24gb2Yg dGhlDQo+ID4+PiAgICBvcmlnaW5hbCBTQ1JBTS1TSEEtMS1QTFVTIG1lY2hhbmlzbS4gIEl0IGFs c28gdXBkYXRlcyB0aGUgU0NSQU0NCj4gPj4+ICAgIHJlZ2lzdHJhdGlvbiBwcm9jZWR1cmVzIG9m IFJGQyA1ODAyLg0KPiA+Pj4NCj4gPj4+IEFuZCBhZGQgdG8gdGhlIEludHJvZHVjdGlvbiBzZWN0 aW9uIHRoZSBmb2xsb3dpbmcgcGFyYWdyYXBoOg0KPiA+Pj4NCj4gPj4+ICAgQWZ0ZXIgcHVibGlj YXRpb24gb2YgUkZDIDU4MDIsIGl0IHdhcyBkaXNjb3ZlcmVkIHRoYXQgVExTIGRvZXMgbm90DQo+ ID4+PiAgIGhhdmUgdGhlIGV4cGVjdGVkIHByb3BlcnRpZXMgZm9yIHRoZSB0bHMtdW5pcXVlIGNo YW5uZWwgYmluZGluZyB0byBiZQ0KPiA+Pj4gICBzZWN1cmUgW1RMUy1TRVNTSU9OLUhBU0hdLiAg VGhlcmVmb3IsIHRoaXMgZG9jdW1lbnQgY29udGFpbiBub3JtYXRpdmUNCj4gPj4+ICAgdGV4dCB0 aGF0IGFwcGxpZXMgdG8gYm90aCB0aGUgb3JpZ2luYWwgU0NSQU0tU0hBLTEtUExVUyBhbmQgdGhl IG5ld2x5DQo+ID4+PiAgIGludHJvZHVjZWQgU0NSQU0tU0hBLTI1Ni1QTFVTIG1lY2hhbmlzbS4N Cj4gPj4+DQo+ID4+PiBJIGNhbid0IGhlbHAgYnV0IGZpbmlzaCB0aGlzIHJlcGVhdGluZyBteSBy YW50IHRoYXQgSSBkb24ndCB0aGluayBhbnkgb2YNCj4gPj4+IHRoaXMgd2lsbCBiZSBlZmZlY3Rp dmUsIGFuZCB0aGF0IHdlIHdpbGwgZmFjZSBhIGxvbmcgdGltZSBvZiBpbnNlY3VyZQ0KPiA+Pj4g U0NSQU0tUExVUyBhZG9wdGlvbi4gIEFwcGxpY2F0aW9uIHdyaXRlcnMgaW4gZ2VuZXJhbCBjYW5u b3Qgc3VmZmljaWVudGx5DQo+ID4+PiBndWFyYW50ZWUgdGhhdCB0aGVpciBUTFMgc3RhY2sgYWx3 YXlzIHVzZXMgVExTLVNFU1NJT04tSEFTSC4gIEFsYXMsIGl0DQo+ID4+PiBzZWVtcyB0aGlzIGFw cHJvYWNoIGlzIHRoZSBtb3N0IGxpa2VseSB0byByZWFjaCBjb25zZW5zdXMsIGFuZCB0aGF0DQo+ ID4+PiBzdGFsbGluZyB0aGlzIGRvY3VtZW50IGZ1cnRoZXIgaXMgbm90IHByb2R1Y3RpdmUuDQo+ ID4+Pg0KPiA+Pj4gL1NpbW9uDQo+ID4+Pg0KPiA+Pj4+PiAgICAgIFRvbnkNCj4gPj4+Pj4NCj4g Pj4+Pj4gT24gNy8yNi8xNSA5OjM0IEFNLCBBbGV4ZXkgTWVsbmlrb3Ygd3JvdGU6DQo+ID4+Pj4+ PiBPbiAyMC8wNy8yMDE1IDIwOjMzLCBTaW1vbiBKb3NlZnNzb24gd3JvdGU6DQo+ID4+Pj4+Pj4g VG9ueSBIYW5zZW4gPHRvbnlAYXR0LmNvbT4gd3JpdGVzOg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ IE5vdGU6IEkgaGF2ZSBOT1QgZG9uZSBhbnl0aGluZyBhYm91dCBpbmNvcnBvcmF0aW5nIHNlc3Np b24NCj4gPj4+Pj4+Pj4gaGFzaGluZyBmb3IgY2hhbm5lbCBiaW5kaW5nLCBhcyBJIHJlbWFpbiB1 bmNvbnZpbmNlZCB0aGF0IHRoaXMgaXMNCj4gPj4+Pj4+Pj4gdGhlIHJpZ2h0IGRvY3VtZW50IHRv IGRvIGFueXRoaW5nIGFib3V0IHRoZSB0b3BpYy4gSWYgeW91IGZlZWwNCj4gPj4+Pj4+Pj4gb3Ro ZXJ3aXNlIGFib3V0IGhhdmluZyA+dGhpcyBkb2N1bWVudDwgbWVudGlvbiBzb21ldGhpbmcgYWJv dXQNCj4gPj4+Pj4+Pj4gY2hhbm5lbCBiaW5kaW5nLCA+cGxlYXNlPCBzdWdnZXN0IHNwZWNpZmlj IHRleHQuDQo+ID4+Pj4+Pj4gWW91IG1heSB1c2U6DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBUbyBi ZSBzZWN1cmUsIFNDUkFNLVNIQS0yNTYtUExVUyBoYXMgdG8gYmUgdXNlZCBvdmVyIGEgVExTIGNo YW5uZWwNCj4gPj4+Pj4+PiB0aGF0IE1VU1QgaGF2ZSBbVExTLVNFU1NJT04tSEFTSF0gbmVnb3Rp YXRlZCwgb3Igc2Vzc2lvbiByZXN1bXB0aW9uDQo+ID4+Pj4+Pj4gTVVTVCBOT1QgaGF2ZSBiZWVu IHVzZWQuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBbVExTLVNFU1NJT04tSEFTSF0NCj4gPj4+Pj4+ PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10bHMtc2Vzc2lvbi1oYXNo LTA2DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBJZiB0aGlzIChvciBzb21lIG90aGVyIHRleHQpIGlz IG5vdCBhZGRlZCwgd2Ugd291bGQgcHVibGlzaCBhDQo+ID4+Pj4+Pj4ga25vd24gaW5zZWN1cmUg cHJvdG9jb2wgd2l0aG91dCBhbnkgZGlzY3Vzc2lvbiBvZiB0aGUgcHJvYmxlbS4NCj4gPj4+Pj4+ IEkgYWdyZWUgdGhhdCB0aGlzIHNob3VsZCBiZSBhZGRlZC4gV2hpbGUgdGhlIHByZWZlcnJlZCB3 YXkgd291bGQgYmUgdG8NCj4gPj4+Pj4+IHVwZGF0ZSB0aGUgYmFzZSBTQ1JBTSBzcGVjaWZpY2F0 aW9uLCBJIHRoaW5rIHRoaXMgbm90ZSBpcyBzdGlsbA0KPiA+Pj4+Pj4gcHJlZmVyYWJsZSB0byBz YXlpbmcgbm90aGluZy4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBL aXR0ZW4gbWFpbGluZyBsaXN0DQo+ID4+IEtpdHRlbkBpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2tpdHRlbg0KPiA+Pg0KPiANCj4gDQo+ From nobody Tue Aug 25 12:39: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 882C01A8A72 for ; Tue, 25 Aug 2015 12:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 Bspru3rxWupY for ; Tue, 25 Aug 2015 12:39:11 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 2EE991A8A6A for ; Tue, 25 Aug 2015 12:39:11 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t7PJcd1t031232 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 25 Aug 2015 21:38:40 +0200 From: Simon Josefsson To: Tony Hansen References: <20150720084611.5447.46804.idtracker@ietfa.amsl.com> <55ACB747.5050006@att.com> <871tg239px.fsf@latte.josefsson.org> <55B4E1D0.7000108@isode.com> <55B78429.2060408@att.com> <55B78838.2020808@isode.com> <87io94vwht.fsf@latte.josefsson.org> <55B7F002.3040308@att.com> <55DC9070.5020302@cs.tcd.ie> <55DCAF17.6040309@att.com> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150825:kitten@ietf.org::i9dxDXUWWMedhZ/X:2u15 X-Hashcash: 1:22:150825:tony@att.com::vuLYPySlmbS7xvp+:5cs6 X-Hashcash: 1:22:150825:alexey.melnikov@isode.com::2LjX69RhA7VAkFBH:3KmR X-Hashcash: 1:22:150825:stephen.farrell@cs.tcd.ie::o++j6nItJ+7NUK3o:r3sr Date: Tue, 25 Aug 2015 21:38:38 +0200 In-Reply-To: <55DCAF17.6040309@att.com> (Tony Hansen's message of "Tue, 25 Aug 2015 14:08:23 -0400") Message-ID: <874mjn6tvl.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-hansen-scram-sha256-03.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, 25 Aug 2015 19:39:14 -0000 --=-=-= Content-Type: text/plain Tony Hansen writes: > Stephen, I actually had an update almost complete, waiting for the LC to > finish. :-) > > I've just submitted a -04. I feel that it addresses everything asked for > during LC. Thank you for your patience. > In particular, Simon, I hope the additions provide everything you > think is needed. Not really, but I believe it provides what we can hope to find people willing to write text on and gain consensus around at this point. Which is as good as it is going to get. So effectively +1 from me. > Diff can be found at > . * Why the colon in 'registers:' in the abstract? It looks a bit strange to me. * Typo 'provdes'. /Simon > > Tony > > On 8/25/15 11:57 AM, Stephen Farrell wrote: >> Hi Tony, all, >> >> The 2nd IETF last call for this is done. This thread is I think >> the only thing that needs to be processed. (Please correct me if >> I'm wrong.) >> >> Tony - will you please make the changes described below and >> submit a -04 with those in? (Feel free to check with folks beforehand >> as to precise wording.) >> >> If you can get that done in the couple of days I'll be happy to put >> this on the Sep 3rd IESG telechat for approval. If it takes longer >> (but pretty please, not so long this time:-) then it'll slip. >> >> Cheers, >> S. >> >> >> >> On 28/07/15 22:11, Tony Hansen wrote: >>> I'll work something in along these lines. Thanks for continuing to bang >>> on this. >>> >>> Tony >>> >>> On 7/28/15 4:49 PM, Simon Josefsson wrote: >>>> Alexey Melnikov writes: >>>> >>>>> Hi Tony, >>>>> >>>>> On 28/07/2015 14:31, Tony Hansen wrote: >>>>>> I will add this text to the security considerations section. >>>>>> >>>>>> This doc >is< updating RFC 5802 (the base SCRAM spec), so what do you >>>>>> think of stating that this also applies to scram-sha-1? >>>>> I am Ok with that. Although I suspect that most implementors are not >>>>> going to look for this advice in your document. >>>> I agree, so there is a problem. To adress it, can we make the abstract >>>> and introduction of scram-sha256 say that the document is ALSO adressing >>>> a security problem in the base RFC 5802 specification? Perhaps going as >>>> far as modifying the title. To me, this normative language related to >>>> TLS-SESSION-HASH have importance to RFC 5802 implementers. >>>> >>>> How about modifying the abstract from: >>>> >>>> This document registers the SASL mechanisms SCRAM-SHA-256 and SCRAM- >>>> SHA-256-PLUS. It also updates the SCRAM registration procedures of >>>> RFC 5802. >>>> >>>> into >>>> >>>> This document registers the SASL mechanisms SCRAM-SHA-256 and SCRAM- >>>> SHA-256-PLUS, and provide guidance for secure implementation of the >>>> original SCRAM-SHA-1-PLUS mechanism. It also updates the SCRAM >>>> registration procedures of RFC 5802. >>>> >>>> And add to the Introduction section the following paragraph: >>>> >>>> After publication of RFC 5802, it was discovered that TLS does not >>>> have the expected properties for the tls-unique channel binding to be >>>> secure [TLS-SESSION-HASH]. Therefor, this document contain normative >>>> text that applies to both the original SCRAM-SHA-1-PLUS and the newly >>>> introduced SCRAM-SHA-256-PLUS mechanism. >>>> >>>> I can't help but finish this repeating my rant that I don't think any of >>>> this will be effective, and that we will face a long time of insecure >>>> SCRAM-PLUS adoption. Application writers in general cannot sufficiently >>>> guarantee that their TLS stack always uses TLS-SESSION-HASH. Alas, it >>>> seems this approach is the most likely to reach consensus, and that >>>> stalling this document further is not productive. >>>> >>>> /Simon >>>> >>>>>> Tony >>>>>> >>>>>> On 7/26/15 9:34 AM, Alexey Melnikov wrote: >>>>>>> On 20/07/2015 20:33, Simon Josefsson wrote: >>>>>>>> Tony Hansen writes: >>>>>>>> >>>>>>>>> Note: I have NOT done anything about incorporating session >>>>>>>>> hashing for channel binding, as I remain unconvinced that this is >>>>>>>>> the right document to do anything about the topic. If you feel >>>>>>>>> otherwise about having >this document< mention something about >>>>>>>>> channel binding, >please< suggest specific text. >>>>>>>> You may use: >>>>>>>> >>>>>>>> To be secure, SCRAM-SHA-256-PLUS has to be used over a TLS channel >>>>>>>> that MUST have [TLS-SESSION-HASH] negotiated, or session resumption >>>>>>>> MUST NOT have been used. >>>>>>>> >>>>>>>> [TLS-SESSION-HASH] >>>>>>>> https://tools.ietf.org/html/draft-ietf-tls-session-hash-06 >>>>>>>> >>>>>>>> If this (or some other text) is not added, we would publish a >>>>>>>> known insecure protocol without any discussion of the problem. >>>>>>> I agree that this should be added. While the preferred way would be to >>>>>>> update the base SCRAM specification, I think this note is still >>>>>>> preferable to saying nothing. >>>>>>> >>>>>>> >>> >>> >>> >>> _______________________________________________ >>> 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 > --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJV3MQ+AAoJEIYLf7sy+BGdnd8H+wXvPnjRarQGniawJsBV9hH0 3Mrp4c372UQbm0+4VJi8d6q+m91Cq/HSN38XWd2/lbAc2PlzyrL4tBq+CU3UpzDN Swo7t+oevz7xuamOWDuccp+HEKS1pJU53zuZntiv4Bzn8vAP77qB0eCg+4nf26A3 3n1uhzmN+rz98bZ+LvtglOm44ZIQGjMVH5624T+N5gfgYoieZrpX9s4AkJieNw5n +aDcm3PEf7+d0XedS+zHX5tR9c4S8KzMDUvavXCTDaY6qp1c14cWIaGtdJi5YzHI 59wGMGPzkH0BzLTA1LbA+OkfqE3DoEWpWt3QJGJtkP7Yb208t2x1RxC+ZR3+2eM= =6xXT -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 25 12:46: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 3F2E31A9177 for ; Tue, 25 Aug 2015 12:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TfueL2X1azkI for ; Tue, 25 Aug 2015 12:46:14 -0700 (PDT) Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 2F4A81A9239 for ; Tue, 25 Aug 2015 12:46:14 -0700 (PDT) Received: from pps.filterd (m0049461.ppops.net [127.0.0.1]) by m0049461.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t7PJhgr1001874 for ; Tue, 25 Aug 2015 15:46:13 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049461.ppops.net-00191d01. with ESMTP id 1wg693gfq3-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 25 Aug 2015 15:46:13 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t7PJkC0P004373 for ; Tue, 25 Aug 2015 15:46:12 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t7PJk8NM004228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 25 Aug 2015 15:46:10 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi131.aldc.att.com (RSA Interceptor) for ; Tue, 25 Aug 2015 19:45:53 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t7PJjqGG024556 for ; Tue, 25 Aug 2015 15:45:53 -0400 Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t7PJjnCU024197 for ; Tue, 25 Aug 2015 15:45:49 -0400 Received: from gacdtq481wh6402.itservices.sbc.com (gacdtq481wh6402.itservices.sbc.com?[135.110.241.64](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150825194543gw1000ce5ne>; Tue, 25 Aug 2015 19:45:48 +0000 X-Originating-IP: [135.110.241.64] To: Simon Josefsson References: <20150720084611.5447.46804.idtracker@ietfa.amsl.com> <55ACB747.5050006@att.com> <871tg239px.fsf@latte.josefsson.org> <55B4E1D0.7000108@isode.com> <55B78429.2060408@att.com> <55B78838.2020808@isode.com> <87io94vwht.fsf@latte.josefsson.org> <55B7F002.3040308@att.com> <55DC9070.5020302@cs.tcd.ie> <55DCAF17.6040309@att.com> <874mjn6tvl.fsf@latte.josefsson.org> From: Tony Hansen Message-ID: <55DCC5E7.3030109@att.com> Date: Tue, 25 Aug 2015 15:45:43 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <874mjn6tvl.fsf@latte.josefsson.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-08-25_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1508250287 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-hansen-scram-sha256-03.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, 25 Aug 2015 19:46:16 -0000 I'm glad for the +1. And thanks for pointing out the typos. I'll hold off on fixing them though until AUTH48. Tony On 8/25/15 3:38 PM, Simon Josefsson wrote: > Tony Hansen writes: > >> Stephen, I actually had an update almost complete, waiting for the LC to >> finish. :-) >> >> I've just submitted a -04. I feel that it addresses everything asked for >> during LC. > Thank you for your patience. > >> In particular, Simon, I hope the additions provide everything you >> think is needed. > Not really, but I believe it provides what we can hope to find people > willing to write text on and gain consensus around at this point. Which > is as good as it is going to get. So effectively +1 from me. > >> Diff can be found at >> . > * Why the colon in 'registers:' in the abstract? It looks a bit strange > to me. > > * Typo 'provdes'. > > /Simon >> Tony >> >> On 8/25/15 11:57 AM, Stephen Farrell wrote: >>> Hi Tony, all, >>> >>> The 2nd IETF last call for this is done. This thread is I think >>> the only thing that needs to be processed. (Please correct me if >>> I'm wrong.) >>> >>> Tony - will you please make the changes described below and >>> submit a -04 with those in? (Feel free to check with folks beforehand >>> as to precise wording.) >>> >>> If you can get that done in the couple of days I'll be happy to put >>> this on the Sep 3rd IESG telechat for approval. If it takes longer >>> (but pretty please, not so long this time:-) then it'll slip. >>> >>> Cheers, >>> S. >>> >>> >>> >>> On 28/07/15 22:11, Tony Hansen wrote: >>>> I'll work something in along these lines. Thanks for continuing to bang >>>> on this. >>>> >>>> Tony >>>> >>>> On 7/28/15 4:49 PM, Simon Josefsson wrote: >>>>> Alexey Melnikov writes: >>>>> >>>>>> Hi Tony, >>>>>> >>>>>> On 28/07/2015 14:31, Tony Hansen wrote: >>>>>>> I will add this text to the security considerations section. >>>>>>> >>>>>>> This doc >is< updating RFC 5802 (the base SCRAM spec), so what do you >>>>>>> think of stating that this also applies to scram-sha-1? >>>>>> I am Ok with that. Although I suspect that most implementors are not >>>>>> going to look for this advice in your document. >>>>> I agree, so there is a problem. To adress it, can we make the abstract >>>>> and introduction of scram-sha256 say that the document is ALSO adressing >>>>> a security problem in the base RFC 5802 specification? Perhaps going as >>>>> far as modifying the title. To me, this normative language related to >>>>> TLS-SESSION-HASH have importance to RFC 5802 implementers. >>>>> >>>>> How about modifying the abstract from: >>>>> >>>>> This document registers the SASL mechanisms SCRAM-SHA-256 and SCRAM- >>>>> SHA-256-PLUS. It also updates the SCRAM registration procedures of >>>>> RFC 5802. >>>>> >>>>> into >>>>> >>>>> This document registers the SASL mechanisms SCRAM-SHA-256 and SCRAM- >>>>> SHA-256-PLUS, and provide guidance for secure implementation of the >>>>> original SCRAM-SHA-1-PLUS mechanism. It also updates the SCRAM >>>>> registration procedures of RFC 5802. >>>>> >>>>> And add to the Introduction section the following paragraph: >>>>> >>>>> After publication of RFC 5802, it was discovered that TLS does not >>>>> have the expected properties for the tls-unique channel binding to be >>>>> secure [TLS-SESSION-HASH]. Therefor, this document contain normative >>>>> text that applies to both the original SCRAM-SHA-1-PLUS and the newly >>>>> introduced SCRAM-SHA-256-PLUS mechanism. >>>>> >>>>> I can't help but finish this repeating my rant that I don't think any of >>>>> this will be effective, and that we will face a long time of insecure >>>>> SCRAM-PLUS adoption. Application writers in general cannot sufficiently >>>>> guarantee that their TLS stack always uses TLS-SESSION-HASH. Alas, it >>>>> seems this approach is the most likely to reach consensus, and that >>>>> stalling this document further is not productive. >>>>> >>>>> /Simon >>>>> >>>>>>> Tony >>>>>>> >>>>>>> On 7/26/15 9:34 AM, Alexey Melnikov wrote: >>>>>>>> On 20/07/2015 20:33, Simon Josefsson wrote: >>>>>>>>> Tony Hansen writes: >>>>>>>>> >>>>>>>>>> Note: I have NOT done anything about incorporating session >>>>>>>>>> hashing for channel binding, as I remain unconvinced that this is >>>>>>>>>> the right document to do anything about the topic. If you feel >>>>>>>>>> otherwise about having >this document< mention something about >>>>>>>>>> channel binding, >please< suggest specific text. >>>>>>>>> You may use: >>>>>>>>> >>>>>>>>> To be secure, SCRAM-SHA-256-PLUS has to be used over a TLS channel >>>>>>>>> that MUST have [TLS-SESSION-HASH] negotiated, or session resumption >>>>>>>>> MUST NOT have been used. >>>>>>>>> >>>>>>>>> [TLS-SESSION-HASH] >>>>>>>>> https://tools.ietf.org/html/draft-ietf-tls-session-hash-06 >>>>>>>>> >>>>>>>>> If this (or some other text) is not added, we would publish a >>>>>>>>> known insecure protocol without any discussion of the problem. >>>>>>>> I agree that this should be added. While the preferred way would be to >>>>>>>> update the base SCRAM specification, I think this note is still >>>>>>>> preferable to saying nothing. >>>>>>>> >>>>>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> From nobody Tue Aug 25 17:28: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 93AE51A1B84 for ; Tue, 25 Aug 2015 17:28:07 -0700 (PDT) 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 d2HeClma1Juq for ; Tue, 25 Aug 2015 17:28:05 -0700 (PDT) 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 985731A1A54 for ; Tue, 25 Aug 2015 17:28:05 -0700 (PDT) X-AuditID: 1209190c-f79296d000000622-c8-55dd0814da64 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-1.mit.edu (Symantec Messaging Gateway) with SMTP id 87.AD.01570.4180DD55; Tue, 25 Aug 2015 20:28:04 -0400 (EDT) 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 t7Q0S3Sj025855 for ; Tue, 25 Aug 2015 20:28:03 -0400 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 t7Q0RxiM001791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 25 Aug 2015 20:28:03 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t7Q0RxIa000913; Tue, 25 Aug 2015 20:27:59 -0400 (EDT) Date: Tue, 25 Aug 2015 20:27:59 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: Message-ID: References: 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+NgFrrOIsWRmVeSWpSXmKPExsUixCmqrSvCcTfU4OJzLoujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEr40j7e8aC5dwVc68sZ2lgXMjZxcjBISFgIrHoqVQXIyeQKSZx 4d56ti5GLg4hgcVMEkfXbWKEcI4zSmx93cMM4dxgkjh44wkLhNPAKLGv+RczSD+LgLZE76Ju NhCbTUBFYuabjWC2iICwxO6t78BqhAWcJW7PPMMOYnMKOEk0T3jPAmLzCjhKtP66BlYjBGR/ mX2aCcQWFdCRWL1/ClSNoMTJmU/AbGYBLYnl07exTGAUmIUkNQtJagEj0ypG2ZTcKt3cxMyc 4tRk3eLkxLy81CJdQ73czBK91JTSTYzg8JPk2cH45qDSIUYBDkYlHt4Z82+HCrEmlhVX5h5i lORgUhLlFWW9GyrEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhPf5ljuhQrwpiZVVqUX5MClpDhYl cd5NP/hChATSE0tSs1NTC1KLYLIyHBxKErzh7EBDBYtS01Mr0jJzShDSTBycIMN5gIa7gNTw Fhck5hZnpkPkTzEqSonzCoIkBEASGaV5cL2w9PCKURzoFWFeIZAqHmBqget+BTSYCWjw+7yb IINLEhFSUg2M9p+n8+6yVU6xCxI0mh4Z93pz5LZXadL/FCafOdJm+71GM2ht/L75xzhnGPue qz1VXlhwf8XzA+f5RDxPLRVUWsvburzqaO7VLztqgltuMVepO92Zmqp9c7729buXdhXEOUka iChNvmVrfHr567nr7aeyPC1f2bDn28Uv3n1Ml3uOuiU63A1xVGIpzkg01GIuKk4EALCFyv3q AgAA Archived-At: Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01 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, 26 Aug 2015 00:28:07 -0000 Reminder: only five days remain in this WGLC. It would be nice to see input from more people, whether on the issue raised by Greg or just general comments. -Ben On Sun, 16 Aug 2015, Benjamin Kaduk wrote: > This message begins the Working Group Last Call (WGLC) of "Public Key > Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness > Extension" . The WGLC will last two > weeks, ending on Sunday, August 30th. The draft is available at: > > https://tools.ietf.org/html/draft-ietf-kitten-pkinit-freshness-01 > > Please review the document and send comments to the Working Group mailing > list or the co-chairs > before the end of the WGLC. Any and all comments on the document are > sought in order to access the strength of consensus. Even if you have > read and commented on this or earlier versions of the draft, please feel > free to comment again. This is particularly important if you found issues > with the previous version. > > As a reminder, comments can be anything from "this looks fine" to "this is > a horrible idea"; they can include suggestions for minor editorial > corrections to significant editorial changes. > > > - Your Kitten Chairs > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From nobody Wed Aug 26 09:50:28 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 1A29A1B2D23 for ; Wed, 26 Aug 2015 09:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 k3nJ5pDvdfsT for ; Wed, 26 Aug 2015 09:50:25 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0639.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:639]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DFB31B2D21 for ; Wed, 26 Aug 2015 09:50:25 -0700 (PDT) Received: from BLUPR06CA0018.namprd06.prod.outlook.com (10.255.219.156) by CY1PR06MB1833.namprd06.prod.outlook.com (10.162.217.15) with Microsoft SMTP Server (TLS) id 15.1.243.23; Wed, 26 Aug 2015 16:50:22 +0000 Received: from BN1BFFO11FD038.protection.gbl (2a01:111:f400:7c10::1:187) by BLUPR06CA0018.outlook.office365.com (2a01:111:e400:83f::28) with Microsoft SMTP Server (TLS) id 15.1.256.15 via Frontend Transport; Wed, 26 Aug 2015 16:50:21 +0000 Authentication-Results: spf=pass (sender IP is 199.135.140.19) smtp.mailfrom=fs.fed.us; MIT.EDU; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of fs.fed.us designates 199.135.140.19 as permitted sender) receiver=protection.outlook.com; client-ip=199.135.140.19; helo=mail.usda.gov; Received: from mail.usda.gov (199.135.140.19) by BN1BFFO11FD038.mail.protection.outlook.com (10.58.144.101) with Microsoft SMTP Server (TLS) id 15.1.256.10 via Frontend Transport; Wed, 26 Aug 2015 16:50:20 +0000 Received: from 001FSN2MPN1-046.001f.mgd2.msft.net ([169.254.6.243]) by 001FSN2MMR1-009.001f.mgd2.msft.net ([199.135.140.19]) with mapi id 14.03.0224.003; Wed, 26 Aug 2015 16:49:41 +0000 From: "Nordgren, Bryce L -FS" To: Benjamin Kaduk , "kitten@ietf.org" Thread-Topic: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01 Thread-Index: AQHQ2De/Y0iFF8yaqUyaE3rJBkVrsZ4de6+AgAEPYOA= Date: Wed, 26 Aug 2015 16:49:41 +0000 Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E8046CD@001FSN2MPN1-046.001f.mgd2.msft.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [170.144.97.141] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD038; 1:UQ9P2Of6r7Eq9vmgjGNnUDQs92sOA2tvR+bAdKIqM/PuKowupp1f/PdyPqCU9vcrnXD1P0MV7Kzomn8CEUlxDunP+b/t07rW5Vw58ZWp9u20yZ08WEzs4VW2Z9/81mktlB9ldN+9w3jKW7x2vGlx2I6rHOhU6SJ30uPBMq/+a6+I4fVnXpyKE2B1DmsMGH+oKMSn6+tH4dFEjQWAAB+qstWM6CnS9FFzOH4PZELs0Uf5jEXYjzjpeOzNFcoVP3gOqtYZ0o0NS0/14PnPPZqeNPJ7qd1cahtdajr1jjG/RrbzkedNMeALIQRhPtCa0UdQY3oF/U4ozlNNHXW/esPjah8dFXHPesnsiJsXFAH6Q+8= X-Forefront-Antispam-Report: CIP:199.135.140.19; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(2980300002)(438002)(3050300001)(189002)(13464003)(24454002)(199003)(377454003)(52044002)(164054003)(46406003)(33656002)(4001540100001)(62966003)(19580395003)(2900100001)(5001830100001)(55846006)(5001770100001)(97736004)(2920100001)(2171001)(5007970100001)(6806004)(5003600100002)(5001860100001)(230783001)(19580405001)(77156002)(46102003)(69596002)(86146001)(26826002)(87936001)(2501003)(74482002)(5004730100002)(102836002)(68736005)(2950100001)(104016003)(23726002)(97756001)(2656002)(50986999)(15975445007)(92566002)(86362001)(76176999)(66066001)(64706001)(50466002)(81156007)(106116001)(189998001)(106466001)(5001960100002)(22746006)(107886002)(54356999)(22756005)(47776003)(110136002)(80862005)(79686003); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR06MB1833; H:mail.usda.gov; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CY1PR06MB1833; 2:5Idx70g90z6A0n36DY8/RvQWe9dkopPCPri9V+DcDsgLMyurStMgxTYbizmRLPQyudhlueB5eAIZkchPwi58jP+04+mfP07jQiy+CFU1zdRKn0zNjVLH8eATuEUBjWHr+sSsbobCNn7Gq9xTt53yhC4KGOBMvDE9KQ6AEmzqTio=; 3:qi+aD/Zd9dePqGoA8xh18WFP3Gied8yai4mdwuUEhNDt3mG0gTFXOtGBFi98knEQbDOC6u3Vfm5RUl7OvzsYtvSY2OmI6frPruYU8RzIW6bkPowQB8zKNErRagL9lc43vgrX1xgkKro0b9KnG3q5eXgmGcREDO0zDGca0baNR6J8Ix2U1BFIAoKBqkyBVafm1Y7mygFv9DkAgzQQxJ/RTj4FPuF0SYvE4d/eqLnpk3lQKvcHoV/krofiouYQK24T; 25:p6HAuy693oHilldZX+BFfLDRgi8O6IWB9hT8lMZQXKk+viKndufhWsnKokDXRwbk0tTM6tWzqiYqwB7ePuk2tkv7MJrq5raiLdKv/IEb4kQwl1ndFRhH1rCXCVD6WelCXglbVwVyoTi0NeoUJPcWxhsOTD4K93/gDj3pJIeYn1wK94G60ZVg1yTPO9c35iZdKzQXOThzmMy4MzX67x9JAkLutZNcVPnCTN4uvwfCuk4qt8s9flQKOsGiWew3mlLSNk+HW0bJHcJiComhQ1NpKQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR06MB1833; X-Microsoft-Exchange-Diagnostics: 1; CY1PR06MB1833; 20:AWZ6rB6TyhRB7UVGdLGh1KL1dYDJS2kS91QADMaWguCsBHSbG9fiQ3tjpCQyUHQDs30/SBvpOaWu+LweS2NU3vEfZo2Se3wsE0CbIxyqe+eI3wyHdpT/oni+4uBozEdFUi/wB4pHp7Z1+feIrBfLXaZxw2GETwm/OfvUS/zyIPEqoW9g4UeVjPAyGTMqJY8rYh5TwhTTL5wMgoPjU7PVlYkre1+m1blQf6vHpjLDzDw2PoNdkONLVfTAFVaIPZ5Z//VThFoIl1qMPLAOA8vWJbn0PEq2IxBCffKnnR1oQ8SJhDE56/o6mYcbxeCavOKJfmm3rjtCkkpMVV16GJXTMDIBc+0gFby0Q1DLr6d6cmqZkxkcKc9BoSDDn5kTT0olOxThPtvNXp5bOPzNLqZGR+wjO/YY2ncCCZdYzpc2Sfc2FxmIMmaFoCGYKQ+RJ5xHbksWUX0YtwXeoGSFZ7cBW01LRNHuvCjeKfcfGJmii0HXozv7MuzodPn5PVJlC6NUroZdzsXJtzJ8qkK8P7Z1GDSwoVo6pv/kDWN2vJUWYgHjo9EJlpXXAgQQ4TKebbVI8DdN35FiINiMJKhSb5dxbXlsOeVtTSpNsq8fJ2NOfq0=; 4:/S8YqEUtbOb6q15X/YHvKcsNQFEHzF3w7aKosuirbcb/B651da4lXkeyYN7k+sm6Vv/aDslJtOTPDStV+fRgfjUqhJgLqrLhtm2t/LoBTyT7khPYluMk6T+ESFhtY6ddzFz8i2z8IL1koznbmqfruJejehUVMohsBXSNSlr1E4L5n9g6QiHRlxC37bNH8+m26topr4EJJpZgMo4SKn0LNJjVvGdhkKjmqBd5VaDQ2ff7pf5DXywEYDdqL6dL67gudvzmRzhJcA03StJp/SHQl0bk05V8qd3bPV8oaBJsnjyOG+ii6xSqkluj4jom+vxx X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:CY1PR06MB1833; BCL:0; PCL:0; RULEID:; SRVR:CY1PR06MB1833; X-Forefront-PRVS: 0680FADD48 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR06MB1833; 23:5Qnc4+kWzLNeFM+seeK/eU0UoyGij+P6oRB75emCh?= =?us-ascii?Q?viMirIz7XVzFOcbgw/oUztQZk7731I1zkoyhHWBjXhxIHZNQLOAWI6Tnp/sM?= =?us-ascii?Q?j82CInKW6V1CWPX50B+pcG7B4t6B2fO5u2zIlZYiwaM94rjR8W7EUMR1TkWq?= =?us-ascii?Q?GubFbC+EHjDU6I2i/FahtDZQqIudChj0mbcbrK0Varhtp8EXTOWLWCicNq0l?= =?us-ascii?Q?Cc9oqqN5INrY9zwUIlhRhpk5uizmMtwsBF0nbKYzlbnm8I8xVYICGeKiOoGD?= =?us-ascii?Q?c5odQ3M64H3jFyFzH9ioedXHQAU2TK3gqEv1XZK7DE+OOkXkKBgoibpiYl2I?= =?us-ascii?Q?gLpbsSfL1nFRaLkZc3of+1LYuG+DHmJ1jPVw8Qy5gST77FzhswTfoeCH0MYw?= =?us-ascii?Q?2O1DjCtWugdcIsyF2cFaFBpKie452xIKOqI9g+mVaROQyMrrypx+PWDjbAUx?= =?us-ascii?Q?lgDR26zD+uROR+fgSFYpg0tN1Nsn5jpdCidtU55i1sYBbaszKSbfM7M62Gw9?= =?us-ascii?Q?STr/QtrnoqXRzaeO8Sk43I1eluF5EIQfgfTI1h3lkNFqz++LOupkqCsrbtKc?= =?us-ascii?Q?rtvv46mpIiyLnuHBEENSVth4ZhtgpvELVrL21JAtyiC7Fs93XJvyd+yLWx13?= =?us-ascii?Q?wkbFo+kGr49IFaDgYK8ROWAXawJADJJHHqwofePQdHy5TvyS4lnK7cOk3vz+?= =?us-ascii?Q?bZNpA5dYO3RlFepgvmnJK28jbPbsKNYXXOiRIIBkAhaXIyrymBNmbh2XjDmW?= =?us-ascii?Q?N0Z/TBormlwv9GkJLQlBe0SQN/mAVPGF/r50hZbVHiNuzxVQsoARcpF8ErTL?= =?us-ascii?Q?ZXOYIhGhrI9tG9UEmPatV6hnTjdannfT2rbC+R592pj8MEULzCRiX6UaaMzx?= =?us-ascii?Q?nSqHzPKuTrs1GVnvLxPgxh9JS0wlDdCguPhBWUoEz1sECflqeWAs6KjQE6vE?= =?us-ascii?Q?CXw56V1wkNoCHLspnmIcBXpq+clYm4fH+ih1yjBRgVA9Bo1d6cHkYH8hQARf?= =?us-ascii?Q?qW/JXnEYRD96hkd9+LPhzt9mI7zom6cPHJ0bgDo9FiWLCRcwqSmRGzyXLOrs?= =?us-ascii?Q?hkWM82duHxMXJkIEmIxCPeQqkwrcZE1FJkxpgsMSsFh4ZAtMcj4rK2b+0Jx9?= =?us-ascii?Q?6U2Krk6mdKVyI/OdzsOw3qlccybzhcsxZVSHTqinHEk54pEVBTjNNQFfb9gF?= =?us-ascii?Q?hCYKMo4PFI2ciumJXda6SSWvNqN79vyjYnjFvCrkrq1Iw27JgewSU5ieMcPs?= =?us-ascii?Q?06pBOYBUyctd7O9Zs1uvKcTOMovWiTEwyOkeL7EelK7v38lkllabpsWYhrRB?= =?us-ascii?Q?11FfDlL6cmcbUICslQRBvjb+Al0KasdwJA/3vQ+oPy4jCswoAji9jYbYkfOJ?= =?us-ascii?Q?ZVsZXp7WFdkN6tJB3SsOyd+Cuqg7LglJN8D0iT4ECN7ziI0aDSomRBumFa6o?= =?us-ascii?Q?L+PUptidapUiyGteORiJ7vmSa1uCyO8lt6jXC4EVRX19wRvTNDuWrFnCO2c4?= =?us-ascii?Q?ZxK4TXooZjUc40dTMllOKgetulLs7FrFEKakHvN5HEg8PvkMzu3Nld7v/UX9?= =?us-ascii?Q?DCCViQOUhIif02AAELa3hm1Y5fKSgyeKT24OCHY7ZlLnG1D352O8AlxF8DOD?= =?us-ascii?Q?uJ4/xMzMxc081u1ojSQ33mzltDIPrafOQrXk2Gl9zUfBZ6pNso6XhaGMTmmf?= =?us-ascii?Q?Sz7gQaMjcq7ni7q5HYtrNLBCQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR06MB1833; 5:Z/4SBrkbAdTkEIGOf/eIc/uiu4U9Y0pS9DXkprIrbRtlaqILt4MdwiMKdiAWsCrSIvcCY/uK8fWHcgS7cqyP9ASf+vUx9w0kN3yNZsgGwxciN6qT36ACv1v/rvHtq/3xAjMZwJwQQ6ov6RcVSlwTIA==; 24:QFs6IxxdSRWXlHvhEzrgchBy0ximZ1vrezIMvv1xc6O7/RjSXCKaTOjylNafrAUstFoFSVYj7wFW2QK0hRiHyU7hp007yJpQIXh9cgXHdvI=; 20:L/NiJfGHhcfQ2ePQJlDgZTY5+9ZVAS9MXVNCidYXSEZ48qaXQ3fdb1pZLILrcgm4h9dzUcj3y5Zw1zrK/9MXPQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: fs.fed.us X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Aug 2015 16:50:20.1397 (UTC) X-MS-Exchange-CrossTenant-Id: 49808c08-7df8-4c41-af62-7a0827de9408 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=49808c08-7df8-4c41-af62-7a0827de9408; Ip=[199.135.140.19]; Helo=[mail.usda.gov] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR06MB1833 Archived-At: Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01 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, 26 Aug 2015 16:50:28 -0000 I'm a little confused as to whether the PA_AS_FRESHNESS field is truly opaq= ue or not. It appears to be, in section 2.3. I take "opaque" to mean that t= he client is not expected to grok the contents of the field and MUST copy i= t to the KRB_AS_REQ exactly as received from the KDC. This would imply that= in section 2.4, the KDC MUST check to make sure that the field returns mat= ches exactly what was sent. Instead, it is validated in an implementation s= pecific way? Can you either clarify the circumstances that would lead to t= he need for "implementation specific" validation (having implications for n= on-opaquish client behavior), or just simplify to checking for an exact mat= ch? In Section 5, "...contributors to the discover" should be "discovery. " Thanks, Bryce > -----Original Message----- > From: Kitten [mailto:kitten-bounces@ietf.org] On Behalf Of Benjamin Kaduk > Sent: Tuesday, August 25, 2015 6:28 PM > To: kitten@ietf.org > Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01 >=20 > Reminder: only five days remain in this WGLC. It would be nice to see in= put > from more people, whether on the issue raised by Greg or just general > comments. >=20 > -Ben >=20 > On Sun, 16 Aug 2015, Benjamin Kaduk wrote: >=20 > > This message begins the Working Group Last Call (WGLC) of "Public Key > > Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness > > Extension" . The WGLC will last > > two weeks, ending on Sunday, August 30th. The draft is available at: > > > > https://tools.ietf.org/html/draft-ietf-kitten-pkinit-freshness-01 > > > > Please review the document and send comments to the Working Group > > mailing list or the co-chairs > > before the end of the WGLC. Any and > > all comments on the document are sought in order to access the > > strength of consensus. Even if you have read and commented on this or > > earlier versions of the draft, please feel free to comment again. > > This is particularly important if you found issues with the previous ve= rsion. > > > > As a reminder, comments can be anything from "this looks fine" to > > "this is a horrible idea"; they can include suggestions for minor > > editorial corrections to significant editorial changes. > > > > > > - Your Kitten Chairs > > > > > > _______________________________________________ > > Kitten mailing list > > Kitten@ietf.org > > https://www.ietf.org/mailman/listinfo/kitten > > >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nobody Wed Aug 26 10:16: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 521E51B2C88 for ; Wed, 26 Aug 2015 10:16:23 -0700 (PDT) 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 dy2KvSbbf88V for ; Wed, 26 Aug 2015 10:16:20 -0700 (PDT) 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 57DD11B2CBE for ; Wed, 26 Aug 2015 10:16:20 -0700 (PDT) X-AuditID: 1209190e-f79c76d000002631-34-55ddf46359cf 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-3.mit.edu (Symantec Messaging Gateway) with SMTP id 17.84.09777.364FDD55; Wed, 26 Aug 2015 13:16:19 -0400 (EDT) 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 t7QHGIV9015449; Wed, 26 Aug 2015 13:16:18 -0400 Received: from [18.101.8.114] (vpn-18-101-8-114.mit.edu [18.101.8.114]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t7QHGFW9010211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 Aug 2015 13:16:17 -0400 Message-ID: <55DDF45F.2080100@mit.edu> Date: Wed, 26 Aug 2015 13:16:15 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Nordgren, Bryce L -FS" , Benjamin Kaduk , "kitten@ietf.org" References: <82E7C9A01FD0764CACDD35D10F5DFB6E8046CD@001FSN2MPN1-046.001f.mgd2.msft.net> In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E8046CD@001FSN2MPN1-046.001f.mgd2.msft.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixCmqrZv85W6oQctmPourb36yWhzdvIrF gcnj9puzLB5LlvxkCmCK4rJJSc3JLEst0rdL4MrYsq6LveAsZ8X8yTNYGxjfsXcxcnBICJhI zDsU3sXICWSKSVy4t54NxBYSWMwkced3TRcjF5C9kVHiwsJLzBDOESaJV7+2M4NU8QqoSSyZ dYoRxGYRUJV48e4oO4jNJqAssX7/VhaQBaICYRJ79qhClAtKnJz5hAXEFhGol+i8+AusVVjA WeL2zDPsEPMPM0qcfNkHNodTIELi7t9PYDazgJ7Ejuu/WCFseYntb+cwT2AUmIVk7iwkZbOQ lC1gZF7FKJuSW6Wbm5iZU5yarFucnJiXl1qka6yXm1mil5pSuokRHKaSfDsYvx5UOsQowMGo xMMr0X43VIg1say4MvcQoyQHk5Io75bXQCG+pPyUyozE4oz4otKc1OJDjBIczEoivC2ngHK8 KYmVValF+TApaQ4WJXHeTT/4QoQE0hNLUrNTUwtSi2CyMhwcShK8fp+BGgWLUtNTK9Iyc0oQ 0kwcnCDDeYCGq4PU8BYXJOYWZ6ZD5E8xKkqJ8zKAJARAEhmleXC9sDTyilEc6BVh3mCQKh5g CoLrfgU0mAlo8Mt4sMEliQgpqQbG1gat+VUTOq/+Z1+9NmJzs6Dd2azVWte3m/E8uJdxfPrk +HdJ5u94PIuOf618mi3BuqaatXzWF6E/FVu+/Nvk8lqxeGvJjR2bHzZo/98Wz5c28xeDvKxg UFk4g1vK/Qbljt2rpPt8vnJw/DXl4/416+1Dm7yHajqNWU+anvR1lE2b/iJ8Cme4EktxRqKh FnNRcSIA/rwrdv4CAAA= Archived-At: Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01 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, 26 Aug 2015 17:16:23 -0000 On 08/26/2015 12:49 PM, Nordgren, Bryce L -FS wrote: > I'm a little confused as to whether the PA_AS_FRESHNESS field is truly opaque or not. It appears to be, in section 2.3. I take "opaque" to mean that the client is not expected to grok the contents of the field and MUST copy it to the KRB_AS_REQ exactly as received from the KDC. This would imply that in section 2.4, the KDC MUST check to make sure that the field returns matches exactly what was sent. Instead, it is validated in an implementation specific way? Can you either clarify the circumstances that would lead to the need for "implementation specific" validation (having implications for non-opaquish client behavior), or just simplify to checking for an exact match? KDCs are usually stateless, and therefore don't have a way to directly verify that the client reflected exactly what the KDC sent. Instead, the KDC could do something like encrypt a timestamp in a key known only to the realm's KDCs; to verify the token, it could decrypt it and check that the timestamp is sufficiently recent. A client could get away with replaying a freshness token from a different request within the allowable time window, but that's not an interesting attack. From nobody Wed Aug 26 11:49: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 617521B30D3 for ; Wed, 26 Aug 2015 11:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ZIQGgipej_EC for ; Wed, 26 Aug 2015 11:49:55 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0098.outbound.protection.outlook.com [65.55.169.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22CA61B2C5B for ; Wed, 26 Aug 2015 11:49:39 -0700 (PDT) Received: from CY1PR0601CA0008.namprd06.prod.outlook.com (10.160.162.18) by SN2PR0601MB0941.namprd06.prod.outlook.com (10.160.57.151) with Microsoft SMTP Server (TLS) id 15.1.243.23; Wed, 26 Aug 2015 18:49:37 +0000 Received: from BN1AFFO11FD033.protection.gbl (2a01:111:f400:7c10::114) by CY1PR0601CA0008.outlook.office365.com (2a01:111:e400:4c00::18) with Microsoft SMTP Server (TLS) id 15.1.243.23 via Frontend Transport; Wed, 26 Aug 2015 18:49:37 +0000 Authentication-Results: spf=pass (sender IP is 199.135.140.16) smtp.mailfrom=fs.fed.us; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of fs.fed.us designates 199.135.140.16 as permitted sender) receiver=protection.outlook.com; client-ip=199.135.140.16; helo=mail.usda.gov; Received: from mail.usda.gov (199.135.140.16) by BN1AFFO11FD033.mail.protection.outlook.com (10.58.52.246) with Microsoft SMTP Server (TLS) id 15.1.256.10 via Frontend Transport; Wed, 26 Aug 2015 18:49:35 +0000 Received: from 001FSN2MMR1-015.001f.mgd2.msft.net (199.135.140.70) by 001FSN2MMR1-006.001f.mgd2.msft.net (199.135.140.16) with Microsoft SMTP Server (TLS) id 14.3.224.3; Wed, 26 Aug 2015 18:49:31 +0000 Received: from 001FSN2MPN1-046.001f.mgd2.msft.net ([169.254.6.243]) by 001FSN2MMR1-015.001f.mgd2.msft.net ([199.135.140.70]) with mapi id 14.03.0224.003; Wed, 26 Aug 2015 18:49:30 +0000 From: "Nordgren, Bryce L -FS" To: Greg Hudson , Benjamin Kaduk , "kitten@ietf.org" Thread-Topic: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01 Thread-Index: AQHQ2De/Y0iFF8yaqUyaE3rJBkVrsZ4de6+AgAEPYOCAAApVgIAAFA5A Date: Wed, 26 Aug 2015 18:49:30 +0000 Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E80479F@001FSN2MPN1-046.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E8046CD@001FSN2MPN1-046.001f.mgd2.msft.net> <55DDF45F.2080100@mit.edu> In-Reply-To: <55DDF45F.2080100@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.7.27.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD033; 1:VixssQF1f/d/JjIUkGmXIM2cdG6sSXFUNwvs8pb4S78K9WB37goWpOZvbCdhQhmtW2M1elYPDfZ+tfnUOsWuELxh+Tf+7dZ+ujqrb/w8XhFNS8DouEEkEmeGYj01lG0E7BHraqNatgrt2py+O9tFbHEi1jgfYcLED9HeV2vnJl/mpuSfggsF/IWN17pxA4vM3QBVVwGgggvY+mLFe0csqDZ7m5xthxwWcowFOz/zcJW2Ns6Pm4oA6c7iFfALterQO2FIvw+lgj6ONWYy5qVLtPlLDFx9ve6uSZrO8BABuHOOy9ksVszbID47F/+ninxWZcRRJbKzzh333uNxDd+m9p8AuvS2SRIplXq15HTDUutuQWgTkA0q+H4v31vfMTXooIOL5tDKtVEWKyEWm8sUWA== X-Forefront-Antispam-Report: CIP:199.135.140.16; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(2980300002)(438002)(3050300001)(13464003)(164054003)(189002)(377454003)(199003)(54356999)(50986999)(55846006)(106116001)(77156002)(106466001)(26826002)(74482002)(46102003)(76176999)(2501003)(46406003)(62966003)(92566002)(5004730100002)(102836002)(68736005)(2950100001)(5007970100001)(2920100001)(2900100001)(19580405001)(97756001)(6806004)(5003600100002)(2171001)(5001860100001)(5001830100001)(5001960100002)(2656002)(86146001)(19580395003)(86362001)(5001770100001)(50466002)(22756005)(33656002)(23726002)(47776003)(66066001)(4001540100001)(189998001)(64706001)(97736004)(230783001)(107886002)(81156007)(87936001)(93886004)(16796002)(69596002)(80862005); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR0601MB0941; H:mail.usda.gov; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; SN2PR0601MB0941; 2:fNDKuMvoatImep/RoYDZrWBTjNQsDoacJ0/xqvyUZzTWwYTpp4TfJalmrBbMBydRz/XPtBAy557/9pzsOdJjj58phLgB+7mJ/N+SpVYaRmuV4HBIRd65q3BQE+0vpJfg2aNdBW62ayKe8OPt+kxAkePdGhYdrpaXbVjmuEDH0ko=; 3:rsfE1p9g4tpQ9tWCl3EQCidGb9LOq2wfUJ65VX4SCv8rPH4swQQmEcXrvoG9sAr51f1r1dXkRZ1J9yOe83FshHURynnTlZOCH2GS30IZx/WEToBRTwufpJ1Goq6bSh/nBiXIJPfbE824wZnNxK00DnHEZZNHMkMfgrNSKMouvSaowyXLSfo141Mtlm+LE/zQoUDqGea77N1lb21kXX6XOy99zCVOWUtkjHwglsTr3vRkh0fumwVXYPDy9Mea/Yik; 25:fNohnCHZb0cnyRkkekH7evCvglDuXlarN/HJ0VSkQ6Nt3wW16xcqzKGfqgGIrd2OTM7L1GZLJM7suDB2/jIY8nhWGMjute+YcIMBDnzmB6atsUll/fhU5OyZ6irJsbGF8/n7rgItQ8wOkNC4Vp/1Hz6YAsTIAzQFgo5tyCKoKwjC80OTq/rCJ6UlGkwJ8O+lsXlERqZ8IGVp6PoDGb7FutjR4fkCGXMT4blUhQyXxMFukYCCknW+r1SeQZVfR2HYdcLw1bSTxyjD6lPzJTQsFQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR0601MB0941; X-Microsoft-Exchange-Diagnostics: 1; SN2PR0601MB0941; 20:+jI39VTqWp5GrKZggsBt6pC83TbBaliPF6a75ZBvnek7RStaYlETH9sjLDarG09L7yGhRhVpP6OawtrhTdColI1WHHEL0BbkXFQDdbcGPXADDCFUJ4ewsBBiTUBX+ImrWAVfq5dmqOy1Qx8qJBCNDKJFwEEUBAu3Vg1/6rtrUpqKgJQqeFWU7K0Fo4er8ICS2I71nckiU4MkLLajH88pq7fGHFq3m7ZsVioroIQY1Mmp1bMfaYhfUadzWFwsPzDU7/Ce+cVltaUEolG3PPoUIVhkodc9yL1NbPGFy6gp+7YNfNlMj2EHSaoPsgpAmAMvF5hG8ddfBIf8jsher9uI9D3mz06C7TsR24du2MFFO7dY2CW0G8upw0vgPtg3iGCeatBle8yizVTL94SZUXagab4zMmLlQD2dwlllsmQlT8VD2okfzsDqTjiidg5DEYsfYiwI7EVJBl4Bpd+Ag5aZ16Je1uzoR/p61MRer5X5Ic5fFrGKUOe312UvPDdL3JODA3GW7QsoMCD0i7ag5dfAoWdSUEa/GBtjLO0GxQ3EteZ2t9j+euSKnMLVVqPPB1BvqUibPQrW8DmJjRR90Tjtix8dkgIVSBTr1A0aK1q/P3g=; 4:ytJ1RFNcHG5cM5HtFUKTvMjc/E+zU0Gv1W0qaMU3gfQsNOXdct1Tw5mveR5Z76UJl9637RHoQSwHoEimSA1z31+5pdJP80wVjGv7TPaTqT723H/hVyPP2GF2HI+RxyPIInYHo4nt/nR/T7Pj8ZuPRFQgJYmQbDaNjvq9Tx3NYS1WLrCnl9daVLRdrlfPrCFo4CM5U411geEngw2viwahg9ifsumsHSlw7MW41266guBKcWl/s0FLHods+067XS05/GC/rkUgLKbI16+IZS9wsdgWiUDkWS3Cr7RTuiYMAGDVOrYeug1wxILHKqog8lcs X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:SN2PR0601MB0941; BCL:0; PCL:0; RULEID:; SRVR:SN2PR0601MB0941; X-Forefront-PRVS: 0680FADD48 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR0601MB0941; 23:oibceflgfII8uk4DlVm+bcwMaQrKrczqGllycTQ?= =?us-ascii?Q?rLaFv9B9qItqghjrEnZN2hSr34W1/xRPdjC61NAx7SAikjLvKTGim2Dt3/lJ?= =?us-ascii?Q?xy/CNl3YfG0g5Wj2AA3u5afs29c50im4bIj4iTLYy9T9/2mFTSYtdMvcGEdx?= =?us-ascii?Q?Az7Zrz3MESO88nzNmdBEca9/Os8vjvkuVMVFfcvqj0P95tsBxgu5R1n4sCRv?= =?us-ascii?Q?z1yK7MOAxmqDo7N7CB9uGsGvJBXJYYP1nUKA2M+nLiKe54p9o8N3XzrsMhlL?= =?us-ascii?Q?KMVTsfrAhRot6zh90mo1n7T8XsIOIJk/gCm2+QOo+wmqR7jrkU2dRTX+pmKd?= =?us-ascii?Q?9LR4yoRD/IPnsyveOj7dpdLTUt5ejXRYlJnneJW5f8fD8AukOBI3oUHmHRyW?= =?us-ascii?Q?zSzdqg44ZoOs2aABctg65obqz2Qn4roQ+knGHX8dDuyK24QIsi+ApLklRxo4?= =?us-ascii?Q?dLUWpGxFygCO/sCPMZlj+pCb2H9TkiIdcAFNuGtkCVIl/cW7Igh1X+tGfxMl?= =?us-ascii?Q?MtdYbX/SJxyK03Yuk0jQv+73kRSULBGr+W3QudAIqxVFoxlXUCWcEhYsz0Ct?= =?us-ascii?Q?RckdW/baQBfnFl/AU6Xoc8DWipzFZKwMS4ZIEXdG0uwzBg1bAf9ChFNnN4bi?= =?us-ascii?Q?DxULtZ77eEADrSEknzvP6PSNviAypD/ZYw0p2H5hdFpJyF8GnhXcgQxvj78c?= =?us-ascii?Q?yova/LKPMlmOjJLkC4EzQEJZi+cVhFLE0Wx6jEEy+IB8HGLZRPEJ36QHxaLl?= =?us-ascii?Q?OuWIE6VOZd8BBth/sHt92reSZH02pcSmTr/ZqlcUeJ0WJpHb4WlP36qqlfzk?= =?us-ascii?Q?yD/PN8S/kbaDiOimF+jWxcdyYN8959bTpmP/dP6Uw4wvkTEYPK2usl6WCBqD?= =?us-ascii?Q?Gs5Yw9PWNcxrRI4H2b8IyZ1Nja0unPXeoqBH3wuK/3LyoLDBHa1u/gOvDn2M?= =?us-ascii?Q?KIJlpXGLdL1Jg4D7+zuWhcoTy/E04+0SJ6XMsxTzQq/t0w5DMdh9i8lNC+aj?= =?us-ascii?Q?BQk4znclEvT60yY17UFXqcxxjYI6l2aB4fiKwXtISSLoHHuLNEp9fCEoNGWa?= =?us-ascii?Q?8a0IB29Il4cz7jcErjF6gZY9M8syTw1ydDDPQ6sra+rpHNwgbE5PWm8q/uQp?= =?us-ascii?Q?ikl7Ux5eLjZ0RCGeEbasU6Xdqz7U0NWb79jILoq7UkMmj4DGJHRdMggsdpZn?= =?us-ascii?Q?KfxA42sReSXrMFrB56/JjmkUjgypgZdSj1UXg/JwYgZVOjBsCRkVhHtwRq+B?= =?us-ascii?Q?PoNe04AaerOYXYpsn+MsyaQFSux6w1gUZ+3XZ0Z8EynOb8dB6hk56YJitouM?= =?us-ascii?Q?ZVBdx7apNwjkCmXeTLv8S2+IxFtNV076LpTGCSNjp15TsGTFpprZVDpIqih4?= =?us-ascii?Q?8/o6L0o9zXVFz9zYy8H1v2H8U4w0TWLVRIYKlXOljCsY2td9X3yvf+DSr243?= =?us-ascii?Q?raVculeCKN2FZf9f+J+/mH/jLcyLqimT/Uq/uXGMHb/cA7sXrJuZ+w4z3ea5?= =?us-ascii?Q?Jl35RCVEq2nUtTYerV4e9LeLM3vIrSTBEj6mQQ7AxX4Z7Z71ppHIwehDxvXI?= =?us-ascii?Q?yab/weUopGQS9CMuE9secVL9BR/jtXz/o0t48Y1k=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR0601MB0941; 5:HDe7f5PfiU5qdrpPkHNCX0Sn8dL2lyexDk4GS+uK8KOdb74HvsGuo6qEEfmPc+p/R1oSO4gTUMtt07oROoWHappNL/jlXTUZhsT2oU8VJog8m7+DCXGENC0/O6qG64+NNveVQgRNkHIsLuRnATyHoQ==; 24:NvGXtAUwTUM6fBw1SJpT70hyD2tMz6ksMPJPOT4t+NTFhpwCWIP9CcwJTkVvBf6+3UQbBKPy6OgfwYoDC0Mr7llBLwzRoXMk6+zVlFJIpho=; 20:HE987OG3jjS5s8tCA9kxOx43a9Q4HmnZHaI8HPcoBVQ8Y2Fn95piaJlZBnu4hiHsuRMpArPtArKtVLrW1C8TiQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: fs.fed.us X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Aug 2015 18:49:35.6034 (UTC) X-MS-Exchange-CrossTenant-Id: 49808c08-7df8-4c41-af62-7a0827de9408 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=49808c08-7df8-4c41-af62-7a0827de9408; Ip=[199.135.140.16]; Helo=[mail.usda.gov] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR0601MB0941 Archived-At: Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01 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, 26 Aug 2015 18:49:57 -0000 > -----Original Message----- > From: Greg Hudson [mailto:ghudson@mit.edu] > Sent: Wednesday, August 26, 2015 11:16 AM > To: Nordgren, Bryce L -FS; Benjamin Kaduk; kitten@ietf.org > Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01 > =20 > KDCs are usually stateless, and therefore don't have a way to directly ve= rify > that the client reflected exactly what the KDC sent. >=20 > Instead, the KDC could do something like encrypt a timestamp in a key > known only to the realm's KDCs; to verify the token, it could decrypt it = and > check that the timestamp is sufficiently recent. A client could get away= with > replaying a freshness token from a different request within the allowable > time window, but that's not an interesting attack. Ah. So this exposes some other unstated assumptions. Somewhere in this draft, probably section 2.2, it needs to be stated that: 1] The KDC MUST NOT reuse the same freshness token on multiple requests; an= d=20 2] The KDC MUST NOT recognize a freshness token as valid if it is received = outside of a specified time window from when it was minted. I'm on the fence about a third statement: "The KDC SHOULD only recognize th= e freshness token as valid if it is included in a request from the client p= rincipal to which it was issued." It indicates intent without imposing cons= traint. If you don't have these two...possibly three constraints, you haven= 't really proven "freshness".=20 I do think some wordsmithed variant of Greg's paragraph above ("Instead, th= e KDC...but that's not an interesting attack.") should be included in the S= ecurity Considerations section. Thanks, Bryce From nobody Wed Aug 26 12:11:05 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 7ADB21A21B8 for ; Wed, 26 Aug 2015 12:11:03 -0700 (PDT) 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 jB2vYA5bBu3n for ; Wed, 26 Aug 2015 12:11:02 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C80171A219E for ; Wed, 26 Aug 2015 12:11:01 -0700 (PDT) X-AuditID: 1209190d-f796f6d000005314-46-55de0f44600f 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-2.mit.edu (Symantec Messaging Gateway) with SMTP id 35.33.21268.44F0ED55; Wed, 26 Aug 2015 15:11:00 -0400 (EDT) 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 t7QJAxrU019786; Wed, 26 Aug 2015 15:11:00 -0400 Received: from [18.101.8.114] (vpn-18-101-8-114.mit.edu [18.101.8.114]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t7QJAvJT015274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 Aug 2015 15:10:58 -0400 Message-ID: <55DE0F41.1030601@mit.edu> Date: Wed, 26 Aug 2015 15:10:57 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Nordgren, Bryce L -FS" , Benjamin Kaduk , "kitten@ietf.org" References: <82E7C9A01FD0764CACDD35D10F5DFB6E8046CD@001FSN2MPN1-046.001f.mgd2.msft.net> <55DDF45F.2080100@mit.edu> <82E7C9A01FD0764CACDD35D10F5DFB6E80479F@001FSN2MPN1-046.001f.mgd2.msft.net> In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E80479F@001FSN2MPN1-046.001f.mgd2.msft.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixG6nruvCfy/UYNtuNYurb36yWhzdvIrF gcnj9puzLB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4N2UPc8Ef/ooPG6YwNjD+4eli5OSQEDCR +LxtHjOELSZx4d56ti5GLg4hgcVMEnu/f4RyNjJK7DvfzwzhHGGSmNUEUsbJwSugJrHjzkaw dhYBVYmLKz+wgthsAsoS6/dvZeli5OAQFQiT2LNHFaJcUOLkzCcsILaIQL1E58VfjCC2sICz xO2ZZ9gh5q9ikvhx5y8jSC+nQITEsxN8IDXMAnoSO67/YoWw5SWat85mnsAoMAvJ2FlIymYh KVvAyLyKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI10gvN7NELzWldBMjKFA5JXl3ML47qHSIUYCD UYmHV6L9bqgQa2JZcWXuIUZJDiYlUd4//4BCfEn5KZUZicUZ8UWlOanFhxglOJiVRHi5ue6F CvGmJFZWpRblw6SkOViUxHk3/eALERJITyxJzU5NLUgtgsnKcHAoSfCG8QE1ChalpqdWpGXm lCCkmTg4QYbzAA1/wwsyvLggMbc4Mx0if4pRUUqc1x6kWQAkkVGaB9cLSySvGMWBXhHmzQNp 5wEmIbjuV0CDmYAGv4y/CzK4JBEhJdXAyP3V0Ogx49bEjH9LNMqc//Q8WHw/L1fosPkDGUHl 14Fez4vNL+tmLLS7vbNYX/rwA93nSuzsccpVT/yqc8s2Mgs1Wdw8k//U/pjlZe3Vcy37YlxO Snqeyr1o3mHP5XWsyWe19KaUjsyLS0vu32CNl/yz4Oqa4s3ev7/Y7w7c6CNwO2Vv8oMJSizF GYmGWsxFxYkAVnyStv8CAAA= Archived-At: Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01 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, 26 Aug 2015 19:11:03 -0000 On 08/26/2015 02:49 PM, Nordgren, Bryce L -FS wrote: > 1] The KDC MUST NOT reuse the same freshness token on multiple requests; and This requirement would have no security or interoperability value. Reusing the same freshness token on multiple requests is a perfectly valid implementation strategy, as long as the token only remains valid for a reasonable length of time. > 2] The KDC MUST NOT recognize a freshness token as valid if it is received outside of a specified time window from when it was minted. I have no objection to adding some wording about this, but I would hope that no implementor would design a "freshness token" which provided no guarantee of freshness! > I'm on the fence about a third statement: "The KDC SHOULD only recognize the freshness token as valid if it is included in a request from the client principal to which it was issued." It indicates intent without imposing constraint. If you don't have these two...possibly three constraints, you haven't really proven "freshness". Even as a SHOULD, this advice would have no security or interoperability value. All we are trying to do is make the client prove that it has recent access to its private key. The only thing we need to know about the freshness token is that a rogue client could not have concocted or intercepted one more than a few minutes in the past which appears to be valid now. We may be using the term "freshness" more loosely than the general cryptography community would; I can't easily find a general definition. If we are using it loosely, that's a common foible of the Kerberos community; there are similar examples in RFCs 4120 and 6113. > I do think some wordsmithed variant of Greg's paragraph above ("Instead, the KDC...but that's not an interesting attack.") should be included in the Security Considerations section. No objection. I'm not really worried about anyone implementing this spec without understanding the architectural reasoning behind it, but more clarity is never a bad thing. From nobody Wed Aug 26 12:21: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 254AD1A88E4 for ; Wed, 26 Aug 2015 12:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TaH8buo9nQ3b for ; Wed, 26 Aug 2015 12:21:04 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0674.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::674]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 025431A88C9 for ; Wed, 26 Aug 2015 12:21:03 -0700 (PDT) Received: from CO2PR06CA032.namprd06.prod.outlook.com (10.141.242.32) by SN1PR0601MB1566.namprd06.prod.outlook.com (10.163.202.16) with Microsoft SMTP Server (TLS) id 15.1.256.15; Wed, 26 Aug 2015 19:21:01 +0000 Received: from BN1AFFO11FD032.protection.gbl (2a01:111:f400:7c10::155) by CO2PR06CA032.outlook.office365.com (2a01:111:e400:142a::32) with Microsoft SMTP Server (TLS) id 15.1.243.23 via Frontend Transport; Wed, 26 Aug 2015 19:21:00 +0000 Authentication-Results: spf=pass (sender IP is 199.135.140.18) smtp.mailfrom=fs.fed.us; mit.edu; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of fs.fed.us designates 199.135.140.18 as permitted sender) receiver=protection.outlook.com; client-ip=199.135.140.18; helo=mail.usda.gov; Received: from mail.usda.gov (199.135.140.18) by BN1AFFO11FD032.mail.protection.outlook.com (10.58.52.186) with Microsoft SMTP Server (TLS) id 15.1.256.10 via Frontend Transport; Wed, 26 Aug 2015 19:20:59 +0000 Received: from 001FSN2MPN1-046.001f.mgd2.msft.net ([169.254.6.243]) by 001FSN2MMR1-008.001f.mgd2.msft.net ([199.135.140.18]) with mapi id 14.03.0224.003; Wed, 26 Aug 2015 19:20:35 +0000 From: "Nordgren, Bryce L -FS" To: Greg Hudson , Benjamin Kaduk , "kitten@ietf.org" Thread-Topic: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01 Thread-Index: AQHQ2De/Y0iFF8yaqUyaE3rJBkVrsZ4de6+AgAEPYOCAAApVgIAAFA5AgAAL/oCAAAFq0A== Date: Wed, 26 Aug 2015 19:20:35 +0000 Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E8047FB@001FSN2MPN1-046.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E8046CD@001FSN2MPN1-046.001f.mgd2.msft.net> <55DDF45F.2080100@mit.edu> <82E7C9A01FD0764CACDD35D10F5DFB6E80479F@001FSN2MPN1-046.001f.mgd2.msft.net> <55DE0F41.1030601@mit.edu> In-Reply-To: <55DE0F41.1030601@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.7.27.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD032; 1:On6ZfPereNaLaTEvEZTEtgKHMs6ZFryiwUI7PZUT2y7xeGbnyYVwogOt1byInWUwvJ5s3EOmtLE+J2bfdgbVzhEfR3ipZpdghplC4urk2nR/23y/oKwTEDQckL2pAFoLIWT+QySMfzK7XfodHtgHdZoK05oz/jOQu8rA0YBtIY5HDlmnQdt/a1P4ZL2SZKFio6N+IcvKgb8ezHyQpeTZhn8NFrT3O1FGgMHNd7Rnm8i5sp4ofhV8Nx6b2tn/wY8cPiyb00tkd0wK1Sit4p1ejqovqarEwnBD3ZXpnliuOh78+cJumcHzaZlNq0gyUD9HcaqgZcstHugRaNNtLpZs6+3yLKN494FKxIcklFzh/tQ= X-Forefront-Antispam-Report: CIP:199.135.140.18; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(2980300002)(438002)(3050300001)(24454002)(479174004)(377454003)(199003)(189002)(33656002)(22756005)(68736005)(77156002)(46406003)(92566002)(69596002)(107886002)(62966003)(5001960100002)(5004730100002)(50466002)(93886004)(2656002)(74482002)(5001860100001)(6806004)(5007970100001)(46102003)(2501003)(5001830100001)(5001770100001)(97736004)(102836002)(230783001)(189998001)(5003600100002)(64706001)(2171001)(2900100001)(54356999)(22746006)(76176999)(86146001)(97756001)(2920100001)(47776003)(66066001)(106466001)(87936001)(55846006)(81156007)(106116001)(86362001)(2950100001)(4001540100001)(26826002)(104016003)(50986999)(23726002)(80862005)(79686003); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0601MB1566; H:mail.usda.gov; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; SN1PR0601MB1566; 2:PG/Fq+ib1BYIsdDDMAhEiIjFlcdv5JQf3vIyOCfeHtG/P6ZtLw0OVsPGOI12VPvDYjnL2y18gR3XkRB2Q2GW6PPqK/pB9AadZpjsDnfI0Uj2FqPg7wo0XmalMom28meLQZgFQ2c4APzVxx8uJO5+KlfNU9ene4/CIPZvMn8C4Aw=; 3:55+5KP1/BlskKzo0SZ2XhLBTwjtfyeK6Dja9wjXrsWVotL+gP8wWCL89nGKGJNwmV09GtTrv6kE4/soy4+QQZHDb8LmJvzBon+KkGYFBvfvyMAOMrU7na52I1NGBE7ESf8opbuozDTaaBRy+A9XMNg09CGWTFXXPASW7zORDdCgaSxmL4hHezhlqIBnXWVZC2bO+CFjIOfdkDCALQ3I8cBi9tjXkGcW3LTdRU1xrOLeUO6Se1oNpBDYtwQFQL2C0; 25:Awm0hbgxLZaUOLnc+n1j4ukLfJvzQE3u2p8mb56v9jY5J1Ainh68OtW17WE1LOFS/LUZmZyOYzcmFXW4bcOAh4s7/cinmwodB15xGtl93DponxBLeokimJpS2BKjg2En4P5Jg2fOhk8i4hcNKZ6H1EsMX5WwPhufX8P7pW//5nZJpoADbzH71fnEwrplT21eW5/vnLAUC0V+s5j7SuyrAUCrqewvvDJDscFfJwONZqpINvbZABlFjMYQoAzsBvf/Sh9MfLkiFzf/MVS4O5Yvxg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0601MB1566; X-Microsoft-Exchange-Diagnostics: 1; SN1PR0601MB1566; 20:G4dh8uHpJIJF/+/efDbCDkgdBccT3lT8maMCRDNDAAT1iDFPYLi8DjpfUxp6bKFf2jt2X9wc+s74Hvkgtwyye4u7HDZ0mGiLYRU6cWW2axtHACiaN9dZb0kRCAk3zPjCTlmt5Tq2ImVeQulPNMP9g+2OULAOX1mf+sTwVpBwKp2wHCX8Brg9Stuohel/qO298gRvR5gvCNBdEJp9DOBleN9rLpYArIWXdsL8jEg15afbw2uea/c01bZ0o1bro8WXx7BmOFP9pylQURWhsfV0PYdqvhv8pqlL7FmHNKWwsSUZllhqLf0x/xTar+v/XQDNYrxgfdIUn8qiOTGnHEKlaJMqc4Qoa6ZrLlx44do7RiI43tmjYf7vlqIGZcKmeLxxOwOoHtGUY2610sWmAU00OvidDwbpjb8Z2A0nPiaZDQG2AKa0nNc5GIH6uUKQrJhuk/DQbqF+Bu4yKmd9b23r2UVPd+CsRJFGWpQ7/sKwDMXhqYjxyAhrVwmPQtfQ1H8KuQ6s40n1wHHeeWpoH/Hxx8B6ADR618DLaukST+zQDqSsldNvxXgbqzf409V9nosS/QmwpZ3DF9/rpb9g4+ut1UpJ5tPXXAgPzEfZ/yvCEKU=; 4:Pue5Fc7oGOnpiragnyLvAb62U0wrD3IN06tX2DmG4tVDmZG57GtrPMKe04GNWwf2dopxhNro7c8bxMIoJpcmirIrz+OqMOKjDsVycp+5BH8DispTTYNGgWO/RpOJqC8YIIsFULM0csXed/jqkr4Cc8umAUjuR7MAB+KwJkd/4BtWmqh/su9+BaCpMnMOeiiJn1RYYVo+AISdDY+hBEL6I2TCnOQCglCchkVXxLMx6DmWEzUyvmechPykltnXBcCkANGxnEHGaiai1yrWBcoDXH2PWsbhamE9pZRic0aAg9p79klumCRZYUDnnPhqhUNJ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:SN1PR0601MB1566; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0601MB1566; X-Forefront-PRVS: 0680FADD48 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR0601MB1566; 23:/8XR4+fZT+yFnWrjCbKLNGVV0EF7Go5+qjaOyWo?= =?us-ascii?Q?Q7sWWBsz1NoUGJNTlFp2REk+SyEfiR2tjZ8j/wBeDUWkPn2EXhJDIyxgpvMm?= =?us-ascii?Q?RM+rLekbYA+q4CZR32Zc2pn5stmbnptEg757uNUUX//7ML2a1PMvY2CmP7AO?= =?us-ascii?Q?3SV/agpsF3BVxe3HDYOkUVBkW6nyWqo8ZivQ2/Mhm+AtAbUb4ANDWVM4SDp+?= =?us-ascii?Q?B6AZZ1lMiwMWsAKHOGAnmw1yd5tggCqzfQQXVBKDYiM2Hcgbwa3nLHuiOgS2?= =?us-ascii?Q?La3g75jgI5yzWbtj9vrMGl8x8Isp8P2vp5oX6bIrvqnJyaa4AQ8QtRrBEUKF?= =?us-ascii?Q?mcHHnWosHXCcvJp0swghfIeEI0ypFzWIqcv8SnNBIp4mG9eTQgC3Juiggiry?= =?us-ascii?Q?hvU1JYJQQYHCEs+jPdgYiyNmxXxlD0dWMPocQZAgIMb5L5ms1paPjGUQkh5v?= =?us-ascii?Q?vHBZCcrL5yPWQI6WZiSQEg82vLQBErMJ/A/LaJm7wv22gwn7hjyOXStNcAfF?= =?us-ascii?Q?sg8HmCbKuVAiF3lckY9ki7Nael0ZYfPr56dYQBHzZSMsy7qhdaDyo7N8dZdB?= =?us-ascii?Q?9ja3mtJgYn7WLS+eDhn5JOe1Ohs3Rxr+rht5P9yyTl0a4EVXzq9gHQJaN7Sr?= =?us-ascii?Q?G9dN/RCYULTLV9W8M/OdyaipItbO1FFv/8wfP9af8WCkVG/Z5/xtbumUaF4g?= =?us-ascii?Q?+BZqam7kDCFo1VIe1CyBXDIHaCeoDYqPj3JtRgrYSiDo3O+7lSQG3/vDcvdO?= =?us-ascii?Q?MDHtBmztgQZ+cEyG3wFUVtMNjfo8aEgHgDkGsj7O4EZnEt1EMoGIj0TjaGSq?= =?us-ascii?Q?EXIwq3ADy50pcqODqaMXNpYP/34Pw5FX36Iurrs0icC2wj7ah7QRoa8oomHs?= =?us-ascii?Q?3ov4I0d1MsJQ9l4ej0RbVheCp2PSrc/Li0FWlQVt7ZPxcdrcJY2vApz5Z/Ry?= =?us-ascii?Q?3vgmiVpv1Cx572cTiZ/IqhE2YoQzebPug9FNh2YNbAc6wuRAqi/xkSrGujg7?= =?us-ascii?Q?nChrEp4q56MzX1iz+g/lnXgPFR30EoSzr2itMabTNygxfBATlIOpnZgYjWyN?= =?us-ascii?Q?FstuzbCMI07eptCD20y9lbG6h9c4aXF+b9Dw18nLv7ao0ZbkxjuceN7123Yn?= =?us-ascii?Q?gqUQRSqM/ap4FxwtN/qRNYHmsAwPmf4sd8bdg5F6568F4w79WAGp7+GXhvlg?= =?us-ascii?Q?C7cupMZBAX/5bEMT0zansiylcmiKgzuga0RfJzLuVnY+uAYmnbwh7J1aWziN?= =?us-ascii?Q?8wFZA2Ia3i9hWcIjPSNFfteqI6tsBij968Z28X2yZRO7t15cZ9oaAk/XzDft?= =?us-ascii?Q?BLCME2DS20ugn4eLjYL+SvWE3df9coINj4I+PrSz8CYoyuOVY8Vl+5OVAZU1?= =?us-ascii?Q?/RzbBya59MWB+kL52ryRaH2+Iip52w2yQxIBdqjjaP0ZwwAP9AJBx364FEl9?= =?us-ascii?Q?RreF2fXZGIVZ5ESkmOElcw7BWL3xnXc6LLWqMiF3EFGN6f8iixesthuo4okd?= =?us-ascii?Q?eznnVqSv+bT8eSvjOl5S5qkDE/KXI+5cM3UMp+W74pNxwyBUDIU6Cu6Tka95?= =?us-ascii?Q?0PB7P1zem+18OmVMXnDupZ5vnIv8lxG/YsqXVz+M=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR0601MB1566; 5:BugdlNtrXuV16bier0wOcRYZLIbfasJyyR8TnyIUFIwsf1z/08AGt7wb/WCGe3ifz72lI9t3g/8fllSpJEzL8O79942m+DP04Ldiw1KkKk9zei9tb0GCwVQz6d9Al8CNJWoTuMNTduHZgJz8RZlVkA==; 24:xGxobpdJedLcCvOjaZvdBg1mFz1u76d34V6QyZ/2YiglQ8FTrH0kCy/IzHCE5ime6UrCJBTaHrRqFTKiM/u7i7HtzgTZObfQO4rE19819M0=; 20:AJjh3ZvXbU46BA83cHUqsFtLoFd6X2OeJBPmEqJTITdy8kUCI56h8lnTPpFT1r71doRtYjFvCJZaPKtZSyw3Fg== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: fs.fed.us X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Aug 2015 19:20:59.5400 (UTC) X-MS-Exchange-CrossTenant-Id: 49808c08-7df8-4c41-af62-7a0827de9408 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=49808c08-7df8-4c41-af62-7a0827de9408; Ip=[199.135.140.18]; Helo=[mail.usda.gov] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0601MB1566 Archived-At: Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01 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, 26 Aug 2015 19:21:06 -0000 > On 08/26/2015 02:49 PM, Nordgren, Bryce L -FS wrote: > > 1] The KDC MUST NOT reuse the same freshness token on multiple > > requests; and >=20 > This requirement would have no security or interoperability value. > Reusing the same freshness token on multiple requests is a perfectly vali= d > implementation strategy, as long as the token only remains valid for a > reasonable length of time. Fair enough. I withdraw the comment. > > 2] The KDC MUST NOT recognize a freshness token as valid if it is recei= ved > outside of a specified time window from when it was minted. >=20 > I have no objection to adding some wording about this, but I would hope t= hat > no implementor would design a "freshness token" which provided no > guarantee of freshness! I have less faith in humanity than most. ;)=20 > > I'm on the fence about a third statement: "The KDC SHOULD only recogniz= e > the freshness token as valid if it is included in a request from the clie= nt > principal to which it was issued." It indicates intent without imposing > constraint. If you don't have these two...possibly three constraints, you > haven't really proven "freshness". >=20 > Even as a SHOULD, this advice would have no security or interoperability > value. ... I concur and withdraw the suggestion. > > I do think some wordsmithed variant of Greg's paragraph above ("Instead= , > the KDC...but that's not an interesting attack.") should be included in t= he > Security Considerations section. >=20 > No objection. I'm not really worried about anyone implementing this spec > without understanding the architectural reasoning behind it, but more cla= rity > is never a bad thing. I think it would be silly to publish a freshness spec which doesn't actuall= y require freshness be proven. ;)=20 Bryce From nobody Wed Aug 26 15:49: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 CA3141B3460 for ; Wed, 26 Aug 2015 15:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, 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 eU2cBDvsaqrT for ; Wed, 26 Aug 2015 15:49:10 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D6141B3449 for ; Wed, 26 Aug 2015 15:49:10 -0700 (PDT) Received: from [93.214.245.15] by 3capp-gmx-bs11.server.lan (via HTTP); Thu, 27 Aug 2015 00:49:08 +0200 MIME-Version: 1.0 Message-ID: From: D.Rogers@gmx.net To: "Greg Hudson" Content-Type: text/html; charset=UTF-8 Date: Thu, 27 Aug 2015 00:49:08 +0200 Importance: normal Sensitivity: Normal In-Reply-To: <55DDF45F.2080100@mit.edu> References: <82E7C9A01FD0764CACDD35D10F5DFB6E8046CD@001FSN2MPN1-046.001f.mgd2.msft.net>, <55DDF45F.2080100@mit.edu> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:gXRqLeJMabsUGcf4X4dqsm9slf+kq+HmKdRwnqaeN3r z6fLfk7I8aOcmR5bnI+EVyZY3LO9p2JuQJPh6CP4YEzBuphioP TKiGrcCaTgWuvPbauLd5sRXO0a4MGl44f0VNbV/cTj1P/tBR/d e/VS6JPMy2R82KAuQl8IljlOEvsjMJi2BHNxccMDow2kz8otfJ 8JJsH1yXvYux8wqP23r6A+L4KT9HgkpJN6aGyo289Nnf5TvDht /FoMVr40NZKRqw8z62SVsC/8GS9Eh5YO0uR1p8kFnk2/c50sbe 9Cf/PM= X-UI-Out-Filterresults: notjunk:1;V01:K0:yx2CDcPZMA8=:M9mUFVIf8cp/pYUpTmqsdm wBtPMuOcIi8CCqCK/DNmkggemeDgR0AxbfqEG45K/PbVDJGXUQqE625ju7zuzbkYCbYTnqN6X VunN/+bPFHEt8vLzuA8GQRfI1eqMrcDmbB710VfwslAvzVa7DqAiFR2vqxnO7heI1hTlv1Uba pYdV1PNvt9TympweOP01w1Jla+u6yEAGEgW7H4GqU0ZSoIOtKSeO5cmqqAE8WIEyQp21rJHXj Xak1URNNELsXfI8bw6rktOiDhlFbslv3HCTyrzJqj9R+eeGVezs6Z+2r3YM/laBOIRHdGC4Ei i3U37oPCxMaGjNl6XiBeiL/3d9K8BIhWyoUk2dVfDfMuf0NWlm/0+Z0mxPe86NSOQvjUHaAva tsq2NKVheIHDL6lt/S7Jl4w/mqw2PT5u31kJmnTdd8QlSl1JvtSW3ztw2SHWDWYS6CNyF/om/ eh4cg61a6g== Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01 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, 26 Aug 2015 22:49:11 -0000
From a practical standpoint I have been against the use of timestamps as a check of freshness (although I have no better solution) since whitnessing some services fall over with catestrophic consequenses for their host companies for precisely that reeason. Ok, that was a few year prior to widespread adoption time synchroised servises, but that is not so far behind us. But there is no reason to pre-suppose that the relevant service dialogue is with a service synchronised via a world atomic clock. Although that may be true of the vast majority of cases of current impementations, to build upon this assumption just builds dependecies upon dependencies. That cannot be good for the future.
 
Gesendet: Mittwoch, 26. August 2015 um 19:16 Uhr
Von: "Greg Hudson" <ghudson@mit.edu>
An: "Nordgren, Bryce L -FS" <bnordgren@fs.fed.us>, "Benjamin Kaduk" <kaduk@mit.edu>, "kitten@ietf.org" <kitten@ietf.org>
Betreff: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01
On 08/26/2015 12:49 PM, Nordgren, Bryce L -FS wrote:
> I'm a little confused as to whether the PA_AS_FRESHNESS field is truly opaque or not. It appears to be, in section 2.3. I take "opaque" to mean that the client is not expected to grok the contents of the field and MUST copy it to the KRB_AS_REQ exactly as received from the KDC. This would imply that in section 2.4, the KDC MUST check to make sure that the field returns matches exactly what was sent. Instead, it is validated in an implementation specific way? Can you either clarify the circumstances that would lead to the need for "implementation specific" validation (having implications for non-opaquish client behavior), or just simplify to checking for an exact match?

KDCs are usually stateless, and therefore don't have a way to directly
verify that the client reflected exactly what the KDC sent.

Instead, the KDC could do something like encrypt a timestamp in a key
known only to the realm's KDCs; to verify the token, it could decrypt it
and check that the timestamp is sufficiently recent. A client could get
away with replaying a freshness token from a different request within
the allowable time window, but that's not an interesting attack.

_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten
From nobody Wed Aug 26 16:32: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 754CC1B351C for ; Wed, 26 Aug 2015 16:32:03 -0700 (PDT) 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 98xUxLnOJI9g for ; Wed, 26 Aug 2015 16:32:02 -0700 (PDT) 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 BE3921B3492 for ; Wed, 26 Aug 2015 16:32:00 -0700 (PDT) X-AuditID: 12074424-f79b46d000001e7f-ba-55de4c6ffc4a 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 85.40.07807.F6C4ED55; Wed, 26 Aug 2015 19:31:59 -0400 (EDT) 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 t7QNVwMJ004224; Wed, 26 Aug 2015 19:31:58 -0400 Received: from [18.101.8.114] (vpn-18-101-8-114.mit.edu [18.101.8.114]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t7QNVtQf029032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 Aug 2015 19:31:57 -0400 Message-ID: <55DE4C6B.1070909@mit.edu> Date: Wed, 26 Aug 2015 19:31:55 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: D.Rogers@gmx.net References: <82E7C9A01FD0764CACDD35D10F5DFB6E8046CD@001FSN2MPN1-046.001f.mgd2.msft.net>, <55DDF45F.2080100@mit.edu> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IR4hRV1s33uRdq8OqRiMXVNz9ZLTputrFZ HN28isWB2eP2m7MsHos37WfzWLLkJ1MAcxSXTUpqTmZZapG+XQJXxqxnSgWveComNraxNTDu 5upi5OSQEDCRaO5cyAphi0lcuLeerYuRi0NIYDGTxIbup+wQzkZGiVmfVkE5R4AyVz4ygrTw CqhJ/LzxgLmLkYODRUBV4utEbZAwm4CyxPr9W1lAwqICYRJ79qhCVAtKnJz5hAXEFhEQkfi7 /QMbiM0sUC+xa/JlJhBbWMBbYvmzv4wQq1YzSZxb/QGsgVMgQuLE1lZGiAZ1iT/zLjFD2PIS zVtnM09gFJyFZMcsJGWzkJQtYGRexSibklulm5uYmVOcmqxbnJyYl5dapGuul5tZopeaUrqJ ERTS7C4qOxibDykdYhTgYFTi4ZVovxsqxJpYVlyZe4hRkoNJSZT3pee9UCG+pPyUyozE4oz4 otKc1OJDjBIczEoivNxcQDnelMTKqtSifJiUNAeLkjjvph98IUIC6YklqdmpqQWpRTBZGQ4O JQleB2+gRsGi1PTUirTMnBKENBMHJ8hwHqDh+iA1vMUFibnFmekQ+VOMilLivPwgCQGQREZp HlwvLOW8YhQHekWYNx2kigeYruC6XwENZgIa/DL+LsjgkkSElFQD42J1lkUcVokTH/9zSy/f 78UilqJ1QYi3i+u6mOHGfUVatav0ch+HT7WOX/Hl55Gpk3ZoBDeuiCkre16beK9ULvTpZ+MP iUzX2J636CvMZBK63p9eGjHnUKDe55XtG2d9dLPccd139461r2JaNz8RPX/hFG9vSrJBQVHs 4305nguboqdf3/imXYmlOCPRUIu5qDgRAMtGvh0UAwAA Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01 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, 26 Aug 2015 23:32:03 -0000 On 08/26/2015 06:49 PM, D.Rogers@gmx.net wrote: > From a practical standpoint I have been against the use of timestamps as > a check of freshness (although I have no better solution) since > whitnessing some services fall over with catestrophic consequenses for > their host companies for precisely that reeason. Ok, that was a few year > prior to widespread adoption time synchroised servises, but that > is not so far behind us. But there is no reason to pre-suppose that the > relevant service dialogue is with a service synchronised via a world > atomic clock. Although that may be true of the vast majority of cases of > current impementations, to build upon this assumption just builds > dependecies upon dependencies. That cannot be good for the future. I don't think this is a concern for the freshness document for three reasons: 1. Other aspects of Kerberos already require that KDC clocks be loosely synchronized with other KDCs in the realm, and with application servers in the realm. (Clients may have somewhat skewed clocks with minimal consequences, as they can detect the offset to the KDC during initial authentication.) 2. As the freshness token is opaque to the client, the use of timestamps in freshness tokens only requires that KDC clocks within the realm are synchronized with each other. It does not add any additional synchronization requirements between KDCs and clients, and application servers are not party to the initial authentication exchange in the first place. 3. The use of timestamps in the freshness token is an implementation decision, not a requirement of the draft. From nobody Sun Aug 30 19:58: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 681801A00E2 for ; Sun, 30 Aug 2015 19:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 E83SSnFGLGa8 for ; Sun, 30 Aug 2015 19:58:12 -0700 (PDT) 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 BA1BE1A0004 for ; Sun, 30 Aug 2015 19:58:10 -0700 (PDT) X-AuditID: 12074423-f79496d000001e58-d5-55e3c2c0e11e 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-6.mit.edu (Symantec Messaging Gateway) with SMTP id 28.B0.07768.0C2C3E55; Sun, 30 Aug 2015 22:58:08 -0400 (EDT) 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 t7V2w8n0004234 for ; Sun, 30 Aug 2015 22:58:08 -0400 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 t7V2w5of005764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 30 Aug 2015 22:58:07 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t7V2w4pj006196; Sun, 30 Aug 2015 22:58:04 -0400 (EDT) Date: Sun, 30 Aug 2015 22:58:04 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: Message-ID: References: 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+NgFnrEIsWRmVeSWpSXmKPExsUixCmqrHvg0ONQgwnndS2Obl7F4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujG9/GxkL7rBWTLt/hLGB8RxLFyMnh4SAicTKxuPsELaYxIV7 69lAbCGBxUwSnU8yuhi5gOzjjBL3D0yBStxgkvj3Mwgi0cAo8WfJBLAEi4C2xLzeKcwgNpuA isTMNxvB4iICwhK7t74DiwsLOEvcnnkGbBungJNE84T3YFfwCjhKvN/+nBligaPEl9mnmUBs UQEdidX7p0DVCEqcnPkEzGYW0JJYPn0bywRGgVlIUrOQpBYwMq1ilE3JrdLNTczMKU5N1i1O TszLSy3SNdPLzSzRS00p3cQICj52F+UdjH8OKh1iFOBgVOLh9eh9HCrEmlhWXJl7iFGSg0lJ lLc9CijEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhDe/BCjHm5JYWZValA+TkuZgURLn3fSDL0RI ID2xJDU7NbUgtQgmK8PBoSTBK3gQqFGwKDU9tSItM6cEIc3EwQkynAdo+N0DIMOLCxJzizPT IfKnGHU5Fvy4vZZJiCUvPy9VSpxXGWSQAEhRRmke3BxY0njFKA70ljBvFUgVDzDhwE16BbSE CWiJn/9DkCUliQgpqQbG+U0isy333ZPd0rySTVGpW3L92ejXxquNCnO3WYQs1Juyw0VctJfj r+J3RVuZuexM/l/yI9er3A/yzU00ungjSHLGvq3LcjSWntv6VH5/285VbR/td3ZfO9Z4u9DG Z7pW2Mb2zW9ktD8IOs6c6bzn84cTz/RveEwrj6n9M8Mss+D/AccHu3juK7EUZyQaajEXFScC APyOH+/1AgAA Archived-At: Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01 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, 31 Aug 2015 02:58:14 -0000 Time for my own review, with no hats on. I don't have much to add that wasn't already included in Greg's comments (and Bryce's note that we should explicitly say that validating the freshness token should validate it's freshness). (Okay, I'll put my chair hat on to thank Greg for the very thorough review -- thanks, Greg!) Basically, just a touch of wordsmithing. In section 2, item 3, the wording could probably be more clear in saying that the freshness token is extracted from the KRB_ERROR message and included in the construction of a new KRB_AS_REQ message. Similarly in section 2.3, indicating that the freshness token goes into a new message from client to KDC would increase the level of clarity. -Ben From nobody Mon Aug 31 08:22: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 06FC31B3C56 for ; Mon, 31 Aug 2015 08:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 7_8eFtbzdqF8 for ; Mon, 31 Aug 2015 08:22:55 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (smtp02.srv.cs.cmu.edu [128.2.217.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEE7A1B4DFE for ; Mon, 31 Aug 2015 08:22:53 -0700 (PDT) Received-SPF: none (cmu.edu: No applicable sender policy available) receiver=smtp02.srv.cs.cmu.edu; identity=mailfrom; envelope-from="jhutz@cmu.edu"; helo="[192.168.202.98]"; client-ip=74.111.102.147 Received: from [192.168.202.98] (pool-74-111-102-147.pitbpa.fios.verizon.net [74.111.102.147]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id t7VFMnL1016003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 31 Aug 2015 11:22:51 -0400 (EDT) Message-ID: <1441034569.5356.73.camel@destiny.pc.cs.cmu.edu> From: Jeffrey Hutzelman To: Benjamin Kaduk Date: Mon, 31 Aug 2015 11:22:49 -0400 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.201 Archived-At: Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01 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, 31 Aug 2015 15:22:57 -0000 On Sun, 2015-08-16 at 11:24 -0400, Benjamin Kaduk wrote: > This message begins the Working Group Last Call (WGLC) of "Public Key > Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness > Extension" . The WGLC will last two > weeks, ending on Sunday, August 30th. The draft is available at: Someone bugged me one too many times, so now I have to actually read this. :-) Looks good overall; the concept is sound, and the specified protocol seems to achieve the intended goal. In some ways, this feels more like a sketch than a detailed protocol spec, but I can't really point to something specific that's missing. The introduction goes into quite a bit of detail about reasons the authors suppose PKINIT's encryption-based exchange is not normally used. The reality is a bit more complicated(*), and also mostly irrelevant to this document. I would cut the second and following sentences of the first paragraph and the following bullet list, and merge the remaining sentence into the following paragraph. That is, the introduction should focus on this extension and the deficiency it corrects, rather than on why some other protocol or mode is not used. The negotiation mechanism is over-complicated. In order for this extension to do any good, the KDC must require its use. Therefore, and because PA-DATA is non-critical, there is no need for a client to advertise support for it. A KDC which supports this extension should simply send PA-AS-FRESHNESS with any preauth-required response where PKINIT would be permitted. Clients which do not support the extension will ignore it (but won't be able to authenticate with PKINIT, of course). Section 2.4 must require the KDC return an error when the freshnessToken is not present, in addition to when it is missing. Somewhere (2.3?) it should be made clear that the client MUST NOT include a freshnessToken if the KDC did not send PK-AS-FRESHNESS. This ought to be obvious, since the client has no value to put there, but IMHO it's better to be specific. Do we need to call out that a client MUST use a freshness token it got during an earlier iteration of the same AS exchange? So, for example, it can't change its mind about principal names or KDC options or requested AD and still expect the freshness token to be valid? -- Jeff (*) It's true that we only specify ECDH, but ECDSA wouldn't help you. It's true that deployed smartcards tend to have only signing keys, but then, they also tend to have only RSA keys, which makes EC irrelevant to the discussion. Also, who says PKINIT is only for smartcards? When we were developing what eventually became RFC4556, one of the most notable use cases involved no smart cards and no keys belonging to users (i.e. people). From nobody Mon Aug 31 11:54: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 A93E41B5990 for ; Mon, 31 Aug 2015 11:54:45 -0700 (PDT) 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 m8t6-GocwOGa for ; Mon, 31 Aug 2015 11:54:43 -0700 (PDT) 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 7AE831B598D for ; Mon, 31 Aug 2015 11:54:42 -0700 (PDT) X-AuditID: 1209190e-f79c76d000002631-43-55e4a2f0cf93 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-3.mit.edu (Symantec Messaging Gateway) with SMTP id C3.18.09777.1F2A4E55; Mon, 31 Aug 2015 14:54:41 -0400 (EDT) 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 t7VIseQA027392; Mon, 31 Aug 2015 14:54:40 -0400 Received: from [18.101.8.99] (vpn-18-101-8-99.mit.edu [18.101.8.99]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t7VIscHU030648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 31 Aug 2015 14:54:39 -0400 Message-ID: <55E4A2ED.2090502@mit.edu> Date: Mon, 31 Aug 2015 14:54:37 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Jeffrey Hutzelman , Benjamin Kaduk References: <1441034569.5356.73.camel@destiny.pc.cs.cmu.edu> In-Reply-To: <1441034569.5356.73.camel@destiny.pc.cs.cmu.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixCmqrPtx0ZNQg/9zWCyuvz/HbnF08yoW ByaP/a3HWD2WLPnJFMAUxWWTkpqTWZZapG+XwJXx6eVD1oJrfBWrHp5mbGD8xt3FyMkhIWAi 8X5/PyuELSZx4d56ti5GLg4hgcVMEnO+fmKEcDYySizrOsIE4RxkkjjZdIIZpIVXQE2iqWk5 mM0ioCqx5vFBFhCbTUBZYv3+rUA2B4eoQJjEnj2qEOWCEidnPgErERFwlej88ocRxGYWEJa4 sH0v2BXCAs4St2eeYQdpFRIokri2jwfE5BSwlVh72hyiWk9ix/VfrBC2vETz1tnMExgFZyFZ MAtJ2SwkZQsYmVcxyqbkVunmJmbmFKcm6xYnJ+blpRbpGuvlZpbopaaUbmIEB68k3w7GrweV DjEKcDAq8fB+6HocKsSaWFZcmXuIUZKDSUmU9+DCJ6FCfEn5KZUZicUZ8UWlOanFhxglOJiV RHhrJwPleFMSK6tSi/JhUtIcLErivJt+8IUICaQnlqRmp6YWpBbBZGU4OJQkeCeCDBUsSk1P rUjLzClBSDNxcIIM5wEafgSkhre4IDG3ODMdIn+KUVFKnLcZJCEAksgozYPrhSWXV4ziQK8I 814DqeIBJia47ldAg5mABvv5PwQZXJKIkJJqYIx+sy0+qfU/c/O7S/OiOIU0xT6bW8f1qObF /o2OOaD/Wlz/huQpjdfSCRu+hthI6qx1DlZbc9X00arfwdtXlzj9qLxTa6U/cccKTfM1RmLT tZVemPBc4jf+VCNSd1r7/Z4znySzN+xxe6n4L1+iPX7+yZeNi7yP+h33yClMdf+gsuarYmL+ eSWW4oxEQy3mouJEAMNhdfIJAwAA Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01 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, 31 Aug 2015 18:54:45 -0000 On 08/31/2015 11:22 AM, Jeffrey Hutzelman wrote: > The negotiation mechanism is over-complicated. In order for this > extension to do any good, the KDC must require its use. Therefore, and > because PA-DATA is non-critical, there is no need for a client to > advertise support for it. A KDC which supports this extension should > simply send PA-AS-FRESHNESS with any preauth-required response where > PKINIT would be permitted. Clients which do not support the extension > will ignore it (but won't be able to authenticate with PKINIT, of > course). I agree, but Microsoft's implementation issues (whether they were arrived at in a justifiable way or not) may trump simplicity on this point. There have been earlier conversations on this topic, most recently in this thread: http://www.ietf.org/mail-archive/web/kitten/current/msg05458.html > Section 2.4 must require the KDC return an error when the freshnessToken > is not present, in addition to when it is missing. I don't think we want a hard requirement for this. Obviously the extension doesn't improve security until it is required, but KDCs should be able to measure the level of client support by requesting freshness tokens without requiring their use. > Do we need to call out that a client MUST use a freshness token it got > during an earlier iteration of the same AS exchange? So, for example, > it can't change its mind about principal names or KDC options or > requested AD and still expect the freshness token to be valid? That's an interesting question. There's no security need for a KDC to bind a freshness token to any parameter of an AS exchange, but there's currently no explicit prohibition against doing so. It's also not unusual for a client to change some aspects of its AS request, particularly timestamps, after receiving a PREAUTH_REQUIRED error. From nobody Mon Aug 31 21:56: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 2DBB91B7EE2; Mon, 31 Aug 2015 21:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 uvYoY5-laR0d; Mon, 31 Aug 2015 21:56:47 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id B78011B7EE0; Mon, 31 Aug 2015 21:56:47 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CB44D187A98; Mon, 31 Aug 2015 21:56:17 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150901045617.CB44D187A98@rfc-editor.org> Date: Mon, 31 Aug 2015 21:56:17 -0700 (PDT) Archived-At: Cc: kitten@ietf.org, drafts-update-ref@iana.org, rfc-editor@rfc-editor.org Subject: [kitten] RFC 7628 on A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth 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, 01 Sep 2015 04:56:49 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7628 Title: A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth Author: W. Mills, T. Showalter, H. Tschofenig Status: Standards Track Stream: IETF Date: August 2015 Mailbox: wmills_92105@yahoo.com, tjs@psaux.com, Hannes.Tschofenig@gmx.net Pages: 21 Characters: 46408 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-kitten-sasl-oauth-23.txt URL: https://www.rfc-editor.org/info/rfc7628 DOI: http://dx.doi.org/10.17487/RFC7628 OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction or by allowing the third-party application to obtain access on its own behalf. This document defines how an application client uses credentials obtained via OAuth over the Simple Authentication and Security Layer (SASL) to access a protected resource at a resource server. Thereby, it enables schemes defined within the OAuth framework for non-HTTP-based application protocols. Clients typically store the user's long-term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a shared secret with higher entropy, i.e., the token. Tokens typically provide limited access rights and can be managed and revoked separately from the user's long-term password. This document is a product of the Common Authentication Technology Next Generation Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC