From nobody Tue Jan 2 15:30:42 2018 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 984CB1242F5; Tue, 2 Jan 2018 15:30:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: Cc: kitten@ietf.org, ietf@ietf.org, draft-ietf-kitten-rfc5653bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151493583156.30989.1076207750886953383@ietfa.amsl.com> Date: Tue, 02 Jan 2018 15:30:31 -0800 Archived-At: Subject: [kitten] Genart telechat review of draft-ietf-kitten-rfc5653bis-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 23:30:32 -0000 Reviewer: Joel Halpern Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-kitten-rfc5653bis-06 Reviewer: Joel Halpern Review Date: 2018-01-02 IETF LC End Date: 2017-09-11 IESG Telechat date: 2018-01-25 Summary: This document is ready for publication as a Proposed Standard RFC Major issues: None Minor issues: Although ID-Nits does not complain about it, I can find no reference to RFCs 2119 or 8174. Some of the uses of "must" int he document are along the lines of "inherently follows", which is not normative language. But other uses are clearly normative in structure. It is unclear why the reference to RFC 2119 was removed as part of this update. Nits/editorial comments: From nobody Tue Jan 2 17:38:31 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1738126CBF; Tue, 2 Jan 2018 17:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 2jJtu5AgXzV4; Tue, 2 Jan 2018 17:38:20 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 78E38124B18; Tue, 2 Jan 2018 17:38:16 -0800 (PST) X-AuditID: 1209190e-cd5ff70000005c56-3b-5a4c34072d4e 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 D0.6A.23638.7043C4A5; Tue, 2 Jan 2018 20:38:15 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w031cD5Q001894; Tue, 2 Jan 2018 20:38:14 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w031c8Ns028183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Jan 2018 20:38:12 -0500 Date: Tue, 2 Jan 2018 19:38:09 -0600 From: Benjamin Kaduk To: Joel Halpern Cc: gen-art@ietf.org, kitten@ietf.org, ietf@ietf.org, draft-ietf-kitten-rfc5653bis.all@ietf.org Message-ID: <20180103013808.GG50827@kduck.kaduk.org> References: <151493583156.30989.1076207750886953383@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <151493583156.30989.1076207750886953383@ietfa.amsl.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRmVeSWpSXmKPExsUixCmqrMtu4hNl8G+dgsWio/uYLa6++sxi 8WzjfBaLj6feMFkc3byKxYHVY8mSn0we56Z8ZwxgiuKySUnNySxLLdK3S+DKWLZrGlvBVu6K L0+fMTcwfuPoYuTkkBAwkVhz+wVLFyMXh5DAYiaJNb+3s0M4Gxgl1p+YyAbhXGGS+HbpMBtI C4uAisSNK58ZQWw2ILuh+zIziC0ioCZxae8OVhCbWSBD4tKBqWD1wgJuEl/23gGr5wVad/VI C1hcSMBZouf9PKi4oMTJmU9YIHq1JG78e8nUxcgBZEtLLP8HdimngIvE79MtYKtEBZQl9vYd Yp/AKDALSfcsJN2zELoXMDKvYpRNya3SzU3MzClOTdYtTk7My0st0jXWy80s0UtNKd3ECA5i Sb4djJMavA8xCnAwKvHwcvR5RwmxJpYVV+YeYpTkYFIS5c1JBQrxJeWnVGYkFmfEF5XmpBYf YpTgYFYS4X2m7BMlxJuSWFmVWpQPk5LmYFES53U30Y4SEkhPLEnNTk0tSC2CyWpwcAi0XDx5 kEmKJS8/L1VJgveeEdAQwaLU9NSKtMycEoRSJg5OkEU8QIvOgdTwFhck5hZnpkPkTzHqcjyb +bqBWQhskJQ47waQIgGQoozSPLg5oKQkkb2/5hWjONCLwrxMxkBVPMCEBjfpFdASJqAlf857 giwpSURISTUwhihf7DUOPaxg/ujDJMWcTQdns+zmDV2wIyRimyTHyjnu164p2WZl9xUarlKz 8D78oDtj6sk/X1MLj3qqC5q7his22Divvne79Y4eH9cORc8rL5fFnPx7bLpGbJoN01LWpaxZ nmxKO2X1v4YUpBo8YnhdJPR0bqSTl9m+Nd1nsva2Rbc08x5QYinOSDTUYi4qTgQA+6XlfiUD AAA= Archived-At: Subject: Re: [kitten] Genart telechat review of draft-ietf-kitten-rfc5653bis-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 01:38:23 -0000 Hi Joel, On Tue, Jan 02, 2018 at 03:30:31PM -0800, Joel Halpern wrote: > Reviewer: Joel Halpern > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-kitten-rfc5653bis-06 > Reviewer: Joel Halpern > Review Date: 2018-01-02 > IETF LC End Date: 2017-09-11 > IESG Telechat date: 2018-01-25 > > Summary: This document is ready for publication as a Proposed Standard RFC > > Major issues: None > > Minor issues: > Although ID-Nits does not complain about it, I can find no reference to > RFCs 2119 or 8174. Some of the uses of "must" int he document are along > the lines of "inherently follows", which is not normative language. But > other uses are clearly normative in structure. It is unclear why the > reference to RFC 2119 was removed as part of this update. Thanks for the review -- I'm a bit surprised that id-nits does not complain about the omission. I do not know why the -00 dropped that clause, but it does seem like the current normal text citing 8174 should be added before publication. -Ben From nobody Tue Jan 2 17:49:32 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565071271DF; Tue, 2 Jan 2018 17:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 mdTqJJumcCNE; Tue, 2 Jan 2018 17:49:20 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 BFAD6127136; Tue, 2 Jan 2018 17:49:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id A13A5A0A420; Tue, 2 Jan 2018 17:49:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1514944160; bh=1UBU+6jKx0DR+chk/FlLAUMyF3BiUNEUys+pBPave+4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=PQLqkZTe48zYBS6NlLO+ckRYTPVv4sE8Vjjw8kdqV84uW1cZvxcG455JAbWzMEeN3 dAhOqahat5/giunE43dsUstUE9aJevtt/o9YlkI84a2idyEdBa6helSxoYmiSt2SfV 8EX69QvZQdeeKec36RQbGpVpKwrIJ5tlVUozDdwQ= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id E46FCA0A41D; Tue, 2 Jan 2018 17:49:19 -0800 (PST) To: Benjamin Kaduk Cc: gen-art@ietf.org, kitten@ietf.org, ietf@ietf.org, draft-ietf-kitten-rfc5653bis.all@ietf.org References: <151493583156.30989.1076207750886953383@ietfa.amsl.com> <20180103013808.GG50827@kduck.kaduk.org> From: "Joel M. Halpern" Message-ID: <25d5a1bb-e7bb-431b-6632-09904a581d77@joelhalpern.com> Date: Tue, 2 Jan 2018 20:49:19 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20180103013808.GG50827@kduck.kaduk.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [kitten] Genart telechat review of draft-ietf-kitten-rfc5653bis-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 01:49:22 -0000 Thanks Ben. That would be good. Yours, Joel On 1/2/18 8:38 PM, Benjamin Kaduk wrote: > Hi Joel, > > On Tue, Jan 02, 2018 at 03:30:31PM -0800, Joel Halpern wrote: >> Reviewer: Joel Halpern >> Review result: Ready with Issues >> >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please wait for direction from your >> document shepherd or AD before posting a new version of the draft. >> >> For more information, please see the FAQ at >> >> . >> >> Document: draft-ietf-kitten-rfc5653bis-06 >> Reviewer: Joel Halpern >> Review Date: 2018-01-02 >> IETF LC End Date: 2017-09-11 >> IESG Telechat date: 2018-01-25 >> >> Summary: This document is ready for publication as a Proposed Standard RFC >> >> Major issues: None >> >> Minor issues: >> Although ID-Nits does not complain about it, I can find no reference to >> RFCs 2119 or 8174. Some of the uses of "must" int he document are along >> the lines of "inherently follows", which is not normative language. But >> other uses are clearly normative in structure. It is unclear why the >> reference to RFC 2119 was removed as part of this update. > > Thanks for the review -- I'm a bit surprised that id-nits does not > complain about the omission. > > I do not know why the -00 dropped that clause, but it does seem like > the current normal text citing 8174 should be added before > publication. > > -Ben > From nobody Tue Jan 2 18:40:45 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B8E127599; Tue, 2 Jan 2018 18:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 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_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 NeRrj-r2xKDu; Tue, 2 Jan 2018 18:40:32 -0800 (PST) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 BFE0F127444; Tue, 2 Jan 2018 18:40:32 -0800 (PST) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.21/8.16.0.21) with SMTP id w032WVqL184386; Wed, 3 Jan 2018 02:40:31 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2017-10-26; bh=ydq46plFUsz8G4hE5iThYQbxB0FxmjyrKDQX3csdwDQ=; b=bjtKy405QArG67AeMxQrgiV1FDnrXFeDyR/UAauERYvCoLHwRWc27/+ov7QpgfLVRxLo dKALp77E2mggLX4X6FYybcGH6PEY/rh8nEH+X3wB7s+fiv4wInY4hgcnZaMXzKJhT/DA C/xR7LuxH+Nf73Hg1jcybNps5+1bs1AFYaP7Nwc5IALH8na6zV+NphqIYk1ANJSd/OYa OQj3eyAIVYiKxf1PNMUEDKjsPONKR1w05aGRETbWZj+/Qb1isAKZSf9FHfxs5HRmrLhi CnK4is4ksuoOs/eSRLFIVsqySchCU9H3xB9ssQ/oL2bVImq8LvrQj5r15RUgkBEc8kL0 sg== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2130.oracle.com with ESMTP id 2f8nbkg4tn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 03 Jan 2018 02:40:30 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w032eTaa013390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 3 Jan 2018 02:40:29 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w032eSvY015958; Wed, 3 Jan 2018 02:40:28 GMT Received: from [192.168.1.101] (/123.122.152.196) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Jan 2018 18:40:28 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Weijun Wang In-Reply-To: <25d5a1bb-e7bb-431b-6632-09904a581d77@joelhalpern.com> Date: Wed, 3 Jan 2018 10:40:23 +0800 Cc: Benjamin Kaduk , gen-art@ietf.org, kitten@ietf.org, ietf@ietf.org, draft-ietf-kitten-rfc5653bis.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <074DA813-1E7F-4C03-AEEE-5D76E8804C31@oracle.com> References: <151493583156.30989.1076207750886953383@ietfa.amsl.com> <20180103013808.GG50827@kduck.kaduk.org> <25d5a1bb-e7bb-431b-6632-09904a581d77@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3445.5.20) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8762 signatures=668650 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801030032 Archived-At: Subject: Re: [kitten] Genart telechat review of draft-ietf-kitten-rfc5653bis-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 02:40:35 -0000 Hi Joel and Ben Author here. I think I've removed the section because in fact none of the keywords = appears as capitalized inside the original document. In fact, RFC 8174 = has "that only UPPERCASE usage of the key words have the defined special = meanings". I assume I'll need to go through the document and make some UPPERCASE = and some not, depending on the actual meanings. Or, since this is a bis and changing the cases would be considered an = re-intepretation of the whole document (which wasn't my goal), is it = more reasonable to keep using RFC 2119 and leave all "must" and = "required" in lowercase? Thanks Weijun > On Jan 3, 2018, at 9:49 AM, Joel M. Halpern = wrote: >=20 > Thanks Ben. That would be good. > Yours, > Joel >=20 > On 1/2/18 8:38 PM, Benjamin Kaduk wrote: >> Hi Joel, >> On Tue, Jan 02, 2018 at 03:30:31PM -0800, Joel Halpern wrote: >>> Reviewer: Joel Halpern >>> Review result: Ready with Issues >>>=20 >>> I am the assigned Gen-ART reviewer for this draft. The General Area >>> Review Team (Gen-ART) reviews all IETF documents being processed >>> by the IESG for the IETF Chair. Please wait for direction from your >>> document shepherd or AD before posting a new version of the draft. >>>=20 >>> For more information, please see the FAQ at >>>=20 >>> . >>>=20 >>> Document: draft-ietf-kitten-rfc5653bis-06 >>> Reviewer: Joel Halpern >>> Review Date: 2018-01-02 >>> IETF LC End Date: 2017-09-11 >>> IESG Telechat date: 2018-01-25 >>>=20 >>> Summary: This document is ready for publication as a Proposed = Standard RFC >>>=20 >>> Major issues: None >>>=20 >>> Minor issues: >>> Although ID-Nits does not complain about it, I can find no = reference to >>> RFCs 2119 or 8174. Some of the uses of "must" int he document = are along >>> the lines of "inherently follows", which is not normative = language. But >>> other uses are clearly normative in structure. It is unclear = why the >>> reference to RFC 2119 was removed as part of this update. >> Thanks for the review -- I'm a bit surprised that id-nits does not >> complain about the omission. >> I do not know why the -00 dropped that clause, but it does seem like >> the current normal text citing 8174 should be added before >> publication. >> -Ben From nobody Tue Jan 2 18:50:34 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64468127444; Tue, 2 Jan 2018 18:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 eviVLmaf8djq; Tue, 2 Jan 2018 18:50:21 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 59B2812426E; Tue, 2 Jan 2018 18:50:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 42933A0A429; Tue, 2 Jan 2018 18:50:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1514947821; bh=lxyeSIH5+RKWXTlbULa2hDlGmPi0R1TMddmj7/yzaMs=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=mFOIbPK84tlQELSQaBsANSH7uLK9XPzEDSnoPEzYpYGmY83ipqsl4vbrTmydlymrW iIy2MrVvOSvWNBL1CfpFP4Ma4rb5ev6+q4z/G2CNLTUoz8kzUszmW9Zm7BTnABX0ZJ JrtRf9ZVvSePuCT4MOtBBKuLH4zRjzOopzR/kYjY= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id EE679A0A426; Tue, 2 Jan 2018 18:50:19 -0800 (PST) To: Weijun Wang Cc: Benjamin Kaduk , gen-art@ietf.org, kitten@ietf.org, ietf@ietf.org, draft-ietf-kitten-rfc5653bis.all@ietf.org References: <151493583156.30989.1076207750886953383@ietfa.amsl.com> <20180103013808.GG50827@kduck.kaduk.org> <25d5a1bb-e7bb-431b-6632-09904a581d77@joelhalpern.com> <074DA813-1E7F-4C03-AEEE-5D76E8804C31@oracle.com> From: "Joel M. Halpern" Message-ID: <41bbbe7d-0f35-78ad-a5cd-673488f3ac09@joelhalpern.com> Date: Tue, 2 Jan 2018 21:50:19 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <074DA813-1E7F-4C03-AEEE-5D76E8804C31@oracle.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [kitten] Genart telechat review of draft-ietf-kitten-rfc5653bis-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 02:50:24 -0000 Personal opinion: Given that to my reading "must" is used on the document in both the RFC 2119 sense and in a conventional English language sense, it would be worth clarifying the intention. As such, I think it would be better to use the 8174 reference and go through changing the right ones to upper case. Yours, Joel On 1/2/18 9:40 PM, Weijun Wang wrote: > Hi Joel and Ben > > Author here. > > I think I've removed the section because in fact none of the keywords appears as capitalized inside the original document. In fact, RFC 8174 has "that only UPPERCASE usage of the key words have the defined special meanings". > > I assume I'll need to go through the document and make some UPPERCASE and some not, depending on the actual meanings. > > Or, since this is a bis and changing the cases would be considered an re-intepretation of the whole document (which wasn't my goal), is it more reasonable to keep using RFC 2119 and leave all "must" and "required" in lowercase? > > Thanks > Weijun > > >> On Jan 3, 2018, at 9:49 AM, Joel M. Halpern wrote: >> >> Thanks Ben. That would be good. >> Yours, >> Joel >> >> On 1/2/18 8:38 PM, Benjamin Kaduk wrote: >>> Hi Joel, >>> On Tue, Jan 02, 2018 at 03:30:31PM -0800, Joel Halpern wrote: >>>> Reviewer: Joel Halpern >>>> Review result: Ready with Issues >>>> >>>> I am the assigned Gen-ART reviewer for this draft. The General Area >>>> Review Team (Gen-ART) reviews all IETF documents being processed >>>> by the IESG for the IETF Chair. Please wait for direction from your >>>> document shepherd or AD before posting a new version of the draft. >>>> >>>> For more information, please see the FAQ at >>>> >>>> . >>>> >>>> Document: draft-ietf-kitten-rfc5653bis-06 >>>> Reviewer: Joel Halpern >>>> Review Date: 2018-01-02 >>>> IETF LC End Date: 2017-09-11 >>>> IESG Telechat date: 2018-01-25 >>>> >>>> Summary: This document is ready for publication as a Proposed Standard RFC >>>> >>>> Major issues: None >>>> >>>> Minor issues: >>>> Although ID-Nits does not complain about it, I can find no reference to >>>> RFCs 2119 or 8174. Some of the uses of "must" int he document are along >>>> the lines of "inherently follows", which is not normative language. But >>>> other uses are clearly normative in structure. It is unclear why the >>>> reference to RFC 2119 was removed as part of this update. >>> Thanks for the review -- I'm a bit surprised that id-nits does not >>> complain about the omission. >>> I do not know why the -00 dropped that clause, but it does seem like >>> the current normal text citing 8174 should be added before >>> publication. >>> -Ben > > From nobody Tue Jan 2 19:08:40 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21AFE127444; Tue, 2 Jan 2018 19:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 ftQewuVpIrs5; Tue, 2 Jan 2018 19:08:27 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 2432A12426E; Tue, 2 Jan 2018 19:08:26 -0800 (PST) X-AuditID: 12074425-a41ff7000000461b-bc-5a4c49289836 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-8.mit.edu (Symantec Messaging Gateway) with SMTP id B0.DB.17947.8294C4A5; Tue, 2 Jan 2018 22:08:25 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w0338MJU012658; Tue, 2 Jan 2018 22:08:23 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w0338IXG016236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Jan 2018 22:08:20 -0500 Date: Tue, 2 Jan 2018 21:08:18 -0600 From: Benjamin Kaduk To: "Joel M. Halpern" Cc: Weijun Wang , gen-art@ietf.org, kitten@ietf.org, ietf@ietf.org, draft-ietf-kitten-rfc5653bis.all@ietf.org Message-ID: <20180103030817.GH50827@kduck.kaduk.org> References: <151493583156.30989.1076207750886953383@ietfa.amsl.com> <20180103013808.GG50827@kduck.kaduk.org> <25d5a1bb-e7bb-431b-6632-09904a581d77@joelhalpern.com> <074DA813-1E7F-4C03-AEEE-5D76E8804C31@oracle.com> <41bbbe7d-0f35-78ad-a5cd-673488f3ac09@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41bbbe7d-0f35-78ad-a5cd-673488f3ac09@joelhalpern.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURzGO/fezbvhjeNUPE6kmkU1nSlJjIoQitzMKOhDtA/V1V234Xa1 e6c4ERKSoJnDTBCHkKWirS++UEli4sBCJae9I0JouWoGtbRGb9o9ii/fnnOe5//8OIc/Taqa ZWraxjs5gWftGrmSUiniU3V7jXmmjGfvGP2d4cek/lVogdIHu29R+vDoF0I/3Ouj9D/au8hs uaGt7RdhGG+IAEN4boo6TZqUh82c3VbGCfuOXFRa7zd9JUsWE8sbWz8RVaA+zg0UNIJZqCbQ KXMDJa2CrQSa6b5HrR66AJqaCwCcUsGXBKr1ilhTcCd68npYhrVc0lU1L0is42AqGmz7RuBh EnoACvUNrYRi4XG0ODAtFdE0I+EWru5eBTQQKNwWkeMMA2PQSNMHCmsSatHbpc8EzpMwCXUs 0fhaAY+iR503V1jxMAUNePxRdQB6N017N017N6ZbAOkDyWZHhc7B2uwiV6ATC1ie5wSdPt1h c6Zz5tIegD876tiuPtD8L9cPIA000QztOWFSydgy0eXwg0Sa0MQzdk662ppfbHZZWdF6QSi1 c6IfIJrUxDHBlDyTijGzrgpOKF6zkmhKk8AYslJNKmhhnVwRx5Vwwpq7h6Zh9eTIEKGm+GKe 0yCmzCCVxAichSsvtNmdG1GCVmBQtARy5WCQWMI6RJtl1R8FOjrYNF9FqlaK1AlMPi6COGQt 5dd78FKhosHKEEiQnhjLZONUtLRy600hCUJIkL8BI4Y42Q1LXQWMoUPG3DPVvb2B3PmzuVrf dMb3u0+1Hem+bYb+Ru3lnwnaAwstmQW1cDQ4u/zRna5ICyyKz03DM2H+97nkN3V/TvaHhf2e 9/xBzYPALBtwLO+YPDV2ZUuhOd+tzoncHq+s7jl/3ZI2EV8TGZswLdyIfXip0d5uH2vpqL+W tn1ZQ4lWNlNLCiL7HwJCLUIvAwAA Archived-At: Subject: Re: [kitten] Genart telechat review of draft-ietf-kitten-rfc5653bis-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 03:08:30 -0000 I am inclined to agree that it is better to change the right ones to upper case -- we really don't have a good reason to still be producing documents with this type of ambiguity anymore. Once that is done we can decide whether the change is substantial enough to require re-running the last call. -Ben On Tue, Jan 02, 2018 at 09:50:19PM -0500, Joel M. Halpern wrote: > Personal opinion: > Given that to my reading "must" is used on the document in both the RFC > 2119 sense and in a conventional English language sense, it would be > worth clarifying the intention. As such, I think it would be better to > use the 8174 reference and go through changing the right ones to upper case. > > Yours, > Joel > > On 1/2/18 9:40 PM, Weijun Wang wrote: > > Hi Joel and Ben > > > > Author here. > > > > I think I've removed the section because in fact none of the keywords appears as capitalized inside the original document. In fact, RFC 8174 has "that only UPPERCASE usage of the key words have the defined special meanings". > > > > I assume I'll need to go through the document and make some UPPERCASE and some not, depending on the actual meanings. > > > > Or, since this is a bis and changing the cases would be considered an re-intepretation of the whole document (which wasn't my goal), is it more reasonable to keep using RFC 2119 and leave all "must" and "required" in lowercase? > > > > Thanks > > Weijun > > > > > >> On Jan 3, 2018, at 9:49 AM, Joel M. Halpern wrote: > >> > >> Thanks Ben. That would be good. > >> Yours, > >> Joel > >> > >> On 1/2/18 8:38 PM, Benjamin Kaduk wrote: > >>> Hi Joel, > >>> On Tue, Jan 02, 2018 at 03:30:31PM -0800, Joel Halpern wrote: > >>>> Reviewer: Joel Halpern > >>>> Review result: Ready with Issues > >>>> > >>>> I am the assigned Gen-ART reviewer for this draft. The General Area > >>>> Review Team (Gen-ART) reviews all IETF documents being processed > >>>> by the IESG for the IETF Chair. Please wait for direction from your > >>>> document shepherd or AD before posting a new version of the draft. > >>>> > >>>> For more information, please see the FAQ at > >>>> > >>>> . > >>>> > >>>> Document: draft-ietf-kitten-rfc5653bis-06 > >>>> Reviewer: Joel Halpern > >>>> Review Date: 2018-01-02 > >>>> IETF LC End Date: 2017-09-11 > >>>> IESG Telechat date: 2018-01-25 > >>>> > >>>> Summary: This document is ready for publication as a Proposed Standard RFC > >>>> > >>>> Major issues: None > >>>> > >>>> Minor issues: > >>>> Although ID-Nits does not complain about it, I can find no reference to > >>>> RFCs 2119 or 8174. Some of the uses of "must" int he document are along > >>>> the lines of "inherently follows", which is not normative language. But > >>>> other uses are clearly normative in structure. It is unclear why the > >>>> reference to RFC 2119 was removed as part of this update. > >>> Thanks for the review -- I'm a bit surprised that id-nits does not > >>> complain about the omission. > >>> I do not know why the -00 dropped that clause, but it does seem like > >>> the current normal text citing 8174 should be added before > >>> publication. > >>> -Ben > > > > From nobody Tue Jan 2 19:49:08 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F03127867; Tue, 2 Jan 2018 19:49:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 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_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 YQAMcRaLtVId; Tue, 2 Jan 2018 19:49:00 -0800 (PST) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 93B11120454; Tue, 2 Jan 2018 19:49:00 -0800 (PST) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.21/8.16.0.21) with SMTP id w033kxvh030114; Wed, 3 Jan 2018 03:48:57 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2017-10-26; bh=uzCsvAlVodnOywdShEsOVKz1OZI/fqpttUH1d3gk3O4=; b=W/kgbtmOmQ81UfGJ44ikuD8DMw8DkAiaQVRgECPym8jUH5Kn51wC4ZCpoNgChs+qHEXN h1B3pEFvTeKbCFcPbmxzgpmMK42B/7WK0rq6bqG+MaE5GT/TMG2qNOEOQnI6SXZuqtLt kVMVYLC6w8QluF8Az9XIF+0jglb+gIOJY98YYsDNeLWxVQyeMb5esIj453zvneR8YXtZ kcTJT8gnFpw2vaIe0k1GULLBHF3/9btlD6fRELmUIhqoS9gA2sI1zGc22B5t0+cfDlyj xDSUnz88T07RlaS2W6hbT5vi2nfEA8bo7hbfwwtERQpH04lCPCS8ii3QqVTICr/JEU5J oQ== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2f8pw0r2j7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 03 Jan 2018 03:48:56 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w033msh1026577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 3 Jan 2018 03:48:55 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w033mrVd028355; Wed, 3 Jan 2018 03:48:53 GMT Received: from [192.168.1.101] (/123.122.152.196) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Jan 2018 19:48:52 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Weijun Wang In-Reply-To: <20180103030817.GH50827@kduck.kaduk.org> Date: Wed, 3 Jan 2018 11:48:47 +0800 Cc: gen-art@ietf.org, kitten , ietf@ietf.org, draft-ietf-kitten-rfc5653bis.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <151493583156.30989.1076207750886953383@ietfa.amsl.com> <20180103013808.GG50827@kduck.kaduk.org> <25d5a1bb-e7bb-431b-6632-09904a581d77@joelhalpern.com> <074DA813-1E7F-4C03-AEEE-5D76E8804C31@oracle.com> <41bbbe7d-0f35-78ad-a5cd-673488f3ac09@joelhalpern.com> <20180103030817.GH50827@kduck.kaduk.org> To: Benjamin Kaduk , "Joel M. Halpern" X-Mailer: Apple Mail (2.3445.5.20) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8762 signatures=668650 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801030049 Archived-At: Subject: Re: [kitten] Genart telechat review of draft-ietf-kitten-rfc5653bis-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 03:49:02 -0000 Thanks for the suggestion. I'll go through the doc and post another = version. --Weijun > On Jan 3, 2018, at 11:08 AM, Benjamin Kaduk wrote: >=20 > I am inclined to agree that it is better to change the right ones to > upper case -- we really don't have a good reason to still be > producing documents with this type of ambiguity anymore. >=20 > Once that is done we can decide whether the change is > substantial enough to require re-running the last call. >=20 > -Ben >=20 > On Tue, Jan 02, 2018 at 09:50:19PM -0500, Joel M. Halpern wrote: >> Personal opinion: >> Given that to my reading "must" is used on the document in both the = RFC=20 >> 2119 sense and in a conventional English language sense, it would be=20= >> worth clarifying the intention. As such, I think it would be better = to=20 >> use the 8174 reference and go through changing the right ones to = upper case. >>=20 >> Yours, >> Joel >>=20 >> On 1/2/18 9:40 PM, Weijun Wang wrote: >>> Hi Joel and Ben >>>=20 >>> Author here. >>>=20 >>> I think I've removed the section because in fact none of the = keywords appears as capitalized inside the original document. In fact, = RFC 8174 has "that only UPPERCASE usage of the key words have the = defined special meanings". >>>=20 >>> I assume I'll need to go through the document and make some = UPPERCASE and some not, depending on the actual meanings. >>>=20 >>> Or, since this is a bis and changing the cases would be considered = an re-intepretation of the whole document (which wasn't my goal), is it = more reasonable to keep using RFC 2119 and leave all "must" and = "required" in lowercase? >>>=20 >>> Thanks >>> Weijun >>>=20 >>>=20 >>>> On Jan 3, 2018, at 9:49 AM, Joel M. Halpern = wrote: >>>>=20 >>>> Thanks Ben. That would be good. >>>> Yours, >>>> Joel >>>>=20 >>>> On 1/2/18 8:38 PM, Benjamin Kaduk wrote: >>>>> Hi Joel, >>>>> On Tue, Jan 02, 2018 at 03:30:31PM -0800, Joel Halpern wrote: >>>>>> Reviewer: Joel Halpern >>>>>> Review result: Ready with Issues >>>>>>=20 >>>>>> I am the assigned Gen-ART reviewer for this draft. The General = Area >>>>>> Review Team (Gen-ART) reviews all IETF documents being processed >>>>>> by the IESG for the IETF Chair. Please wait for direction from = your >>>>>> document shepherd or AD before posting a new version of the = draft. >>>>>>=20 >>>>>> For more information, please see the FAQ at >>>>>>=20 >>>>>> . >>>>>>=20 >>>>>> Document: draft-ietf-kitten-rfc5653bis-06 >>>>>> Reviewer: Joel Halpern >>>>>> Review Date: 2018-01-02 >>>>>> IETF LC End Date: 2017-09-11 >>>>>> IESG Telechat date: 2018-01-25 >>>>>>=20 >>>>>> Summary: This document is ready for publication as a Proposed = Standard RFC >>>>>>=20 >>>>>> Major issues: None >>>>>>=20 >>>>>> Minor issues: >>>>>> Although ID-Nits does not complain about it, I can find no = reference to >>>>>> RFCs 2119 or 8174. Some of the uses of "must" int he = document are along >>>>>> the lines of "inherently follows", which is not normative = language. But >>>>>> other uses are clearly normative in structure. It is = unclear why the >>>>>> reference to RFC 2119 was removed as part of this update. >>>>> Thanks for the review -- I'm a bit surprised that id-nits does not >>>>> complain about the omission. >>>>> I do not know why the -00 dropped that clause, but it does seem = like >>>>> the current normal text citing 8174 should be added before >>>>> publication. >>>>> -Ben >>>=20 >>>=20 From nobody Thu Jan 4 07:41:55 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAAE7128D2E for ; Thu, 4 Jan 2018 07:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 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_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 gIFm9eidtAqE for ; Thu, 4 Jan 2018 07:41:53 -0800 (PST) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 3A4381267BB for ; Thu, 4 Jan 2018 07:41:53 -0800 (PST) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.21/8.16.0.21) with SMTP id w04FcKeH004856; Thu, 4 Jan 2018 15:41:52 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2017-10-26; bh=9ofIhBkoehhYJu1FUKP9njtPeFAcNJsr36X0T3tc+gM=; b=vk2A83kJQVmOFYsnRatiMj95SyMxq5fMTiDXD9BL/og3pQrsNGgkSwkKq6pWQTD2bZJ8 sWGRXO6DP1QeSeg5g7RrZmzetRvHZRgqv4Spvy0ABoySp2BmFyjSTavdvTJNu0ZWgHyV tNfk2YxJ0gs+bSVZ0Y/CfA6AICUHV4aaBBviXpZ0CeZ5X9fN87a+NhoRQ0Qz/TN9BX5S tyk0EDGejJVy6iin6VutE0rZEGRmECbgvdrqjAdnyaREjuXQAibfemi1fdQKC6nNYwku xmW6zm1LMa9TT0Eul1PMVeX04I9JoVjYEL47Ak9OlqN9rPDpnzFFPjLacVOsMP9d4M3n 4w== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2f9p320dnm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 04 Jan 2018 15:41:52 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w04Ffo9T031794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 4 Jan 2018 15:41:51 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w04Ffogs023280; Thu, 4 Jan 2018 15:41:50 GMT Received: from [192.168.1.101] (/123.122.152.196) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Jan 2018 07:41:49 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Weijun Wang In-Reply-To: <20180103172640.GI50827@kduck.kaduk.org> Date: Thu, 4 Jan 2018 23:41:43 +0800 Cc: kitten Content-Transfer-Encoding: quoted-printable Message-Id: <013AE0DE-06E9-42F8-98CD-BB70686A5494@oracle.com> References: <151493583156.30989.1076207750886953383@ietfa.amsl.com> <20180103013808.GG50827@kduck.kaduk.org> <25d5a1bb-e7bb-431b-6632-09904a581d77@joelhalpern.com> <074DA813-1E7F-4C03-AEEE-5D76E8804C31@oracle.com> <41bbbe7d-0f35-78ad-a5cd-673488f3ac09@joelhalpern.com> <20180103030817.GH50827@kduck.kaduk.org> <20180103172640.GI50827@kduck.kaduk.org> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.5.20) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8763 signatures=668651 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=521 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801040216 Archived-At: Subject: [kitten] draft-ietf-kitten-rfc5653bis-07 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 15:41:55 -0000 Hi Ben I've posted a new draft at = http://cr.openjdk.java.net/~weijun/rfc5653bis/draft-ietf-kitten-rfc5653bis= -07.html The only changes since -06 are: 1. Newly added "2. Notational Conventions". 2. Convert some of the keywords to UPPERCASE. For every occurrence of the keywords, I've marked the UPPERCASE ones red = and lowercase ones gray so you can easily spot them. Line numbers are = added to the text. I converted most "must" and "should" to UPPERCASE. There are many = "may"s. For those having a subject of "mechanism" or "application", I = usually leave them in lowercase. For "implementation", I usually change = it to UPPERCASE. Please take a review. I generated this HTML from the output of "xml2rfc = --raw". The "xml2rfc --html" looks too modern for me. If you know a way = to generate an HTML like https://tools.ietf.org/html/rfc5653 which has a = plain text layout while containing links I'll be happy to create my page = based on it. Thanks Weijun= From nobody Mon Jan 8 18:57:40 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63164120727 for ; Mon, 8 Jan 2018 18:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 Mv0Vno1HK23C for ; Mon, 8 Jan 2018 18:57:37 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 0AAB91200B9 for ; Mon, 8 Jan 2018 18:57:36 -0800 (PST) X-AuditID: 1209190d-7f9ff700000034de-3a-5a542f9e685c 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 7F.7B.13534.F9F245A5; Mon, 8 Jan 2018 21:57:36 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w092vWG3028824 for ; Mon, 8 Jan 2018 21:57:33 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w092vSgu026402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 8 Jan 2018 21:57:31 -0500 Date: Mon, 8 Jan 2018 20:57:29 -0600 From: Benjamin Kaduk To: kitten@ietf.org Message-ID: <20180109025728.GQ25484@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUixG6nrrtAPyTK4EuqxdHNq1gcGD2WLPnJ FMAYxWWTkpqTWZZapG+XwJUx++FcxoI5TBVP5/QxNjDeZexi5OSQEDCR6O08wg5iCwksZpKY PkcDwj7GKLHhiGUXIxeQ/YpJ4mrjTbAiFgEViecn94PZbEB2Q/dlZhBbREBYYvfWd2C2sICW xJT9Z1lBbF6gBTduv2eBsAUlTs58AmYzA9Xc+PeSqYuRA8iWllj+jwMkLCqgLLG37xD7BEbe WUg6ZiHpmIXQsYCReRWjbEpulW5uYmZOcWqybnFyYl5eapGukV5uZoleakrpJkZQEHFK8u5g /HfX6xCjAAejEg9vQXtwlBBrYllxZe4hRkkOJiVRXlHngCghvqT8lMqMxOKM+KLSnNTiQ4wS HMxKIry+84HKeVMSK6tSi/JhUtIcLErivO4m2lFCAumJJanZqakFqUUwWRkODiUJ3ni9kCgh waLU9NSKtMycEoQ0EwcnyHAeoOHaIDW8xQWJucWZ6RD5U4zGHDceXv/DxPFs5usGZiGWvPy8 VClxXjFgLAsJgJRmlObBTQMlAons/TWvGMWBnhPm3QkykAeYRODmvQJaxQS06t2+QJBVJYkI KakGxvkVjtFXQifJd/+ct6pMsrH/Mqu5eOV+h/IX4sevn7U+Int9Wktq68Il7gG/7VNFGWMz 4/LPphdy5j6K/nqQ8dchJjHJGO32+ckHXT/NYPPdWcHovXayY/TjFA/VhgWpSREuAfu/lha9 3L2g1rPh3VP3ut8WLcoa/nJ7dWNanyc0aR1tOTdFiaU4I9FQi7moOBEAIdxT2d8CAAA= Archived-At: Subject: [kitten] Any topics for IETF 101 (London)? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 02:57:38 -0000 Hi all, Session request submission is open for IETF 101 in London (March 17-23). Please let the chairs know if you will be attending and have topics you would like to discuss; if there is insufficient interest, we will not request a session. Thanks, Ben for the Chairs From nobody Sat Jan 13 04:44:36 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A3B124419 for ; Sat, 13 Jan 2018 04:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 H76KwAvU8y7g for ; Sat, 13 Jan 2018 04:44:33 -0800 (PST) Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) (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 90542120107 for ; Sat, 13 Jan 2018 04:44:33 -0800 (PST) Received: by mail-wm0-f54.google.com with SMTP id f71so2024489wmf.0 for ; Sat, 13 Jan 2018 04:44:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:cc:message-id:date :user-agent:mime-version:in-reply-to; bh=WYAGl5AcPiHlhBt3/8QpGRRbto1sKWKqSix2tWxBKqs=; b=cRxblWmr71F26y8ugp6nSup8+7p0AqeOE6bDLmR2Z55BmfhnRKI89IeCuEgT1us/y0 hhdynrXve/qDZnZADdfuKyXJCA0Jkj4BEMRBsOSeABc5uvYSvqCzuH5ptMx1ahmTpale 0ebmXDacpEi5YDUMcD4hQ0SF3OdJKzqd9aO2PEa4aQF9HK0DeGrzoseIe0ibwqqgg8Oi Zoum8Cw3CaejOMwtf1dA6bOS6AEEKVHNd6YT8EHHTq3NyfYF+VBsi4psMDYAngElcdMz gFvf23uTO/xjij6lFrIFOyqw02gAUBrj7ZtAFriXQpgxyjTqjX/i2E1X2hbuAZ3BRIZ/ IHyA== X-Gm-Message-State: AKwxytehYcvyeZ2LE463yIx3t1rHjBtNFpmK8P5cyzU4Pwi6VpOVViAs eRU1pdPf5JCqpnuIuVK3nck= X-Google-Smtp-Source: ACJfBot4NnfuFXcKu4CoaMRttk8x0YdNMS06R5qpwe21VGTPsrJJnN4YqD3qUqA+40Myix5D1QJLgQ== X-Received: by 10.80.186.55 with SMTP id g52mr16644817edc.25.1515847471778; Sat, 13 Jan 2018 04:44:31 -0800 (PST) Received: from ?IPv6:2001:a62:171f:8701:3f28:93df:d836:a37d? ([2001:a62:171f:8701:3f28:93df:d836:a37d]) by smtp.googlemail.com with ESMTPSA id g20sm15489180edb.75.2018.01.13.04.44.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Jan 2018 04:44:30 -0800 (PST) To: kitten@ietf.org References: <20180109025728.GQ25484@kduck.kaduk.org> From: Florian Schmaus Message-ID: <4792117a-1c2f-9f71-3407-c9010d1fbf15@geekplace.eu> Date: Sat, 13 Jan 2018 13:44:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20180109025728.GQ25484@kduck.kaduk.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="yWzNa85KmMP80QE8KbfIF7WIUgnXEnctR" Archived-At: Subject: Re: [kitten] Any topics for IETF 101 (London)? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 12:44:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --yWzNa85KmMP80QE8KbfIF7WIUgnXEnctR Content-Type: multipart/mixed; boundary="vN5oMflw3D2laRRk0hlD2kMIdEnPjHTSj"; protected-headers="v1" From: Florian Schmaus To: kitten@ietf.org Cc: Dave Cridland Message-ID: <4792117a-1c2f-9f71-3407-c9010d1fbf15@geekplace.eu> Subject: Re: [kitten] Any topics for IETF 101 (London)? References: <20180109025728.GQ25484@kduck.kaduk.org> In-Reply-To: <20180109025728.GQ25484@kduck.kaduk.org> --vN5oMflw3D2laRRk0hlD2kMIdEnPjHTSj Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 09.01.2018 03:57, Benjamin Kaduk wrote: > Hi all, >=20 > Session request submission is open for IETF 101 in London (March > 17-23). Please let the chairs know if you will be attending and > have topics you would like to discuss; if there is insufficient > interest, we will not request a session. I would love to give a short introduction about the Hashed Token SASl mechanism [1] and gather some feedback. But I first need to see if my university would cover the travel costs. I should have this sorted out by the end of the month. Dave Cridland also recently submitted a related I-D [2] where he introduces the CLIENT-KEY SASL mechanism. Given that London is basically just around the corner for him, I wouldn't be surprised and happy if we could meet at IETF 101. But if it doesn't work out, there is always IETF 101 + n (n > 0). :) - Florian 1: https://mailarchive.ietf.org/arch/msg/kitten/v7X6WBMxMDpNGvXu9N5DEggVd= mQ 2: https://datatracker.ietf.org/doc/draft-cridland-kitten-clientkey/ --vN5oMflw3D2laRRk0hlD2kMIdEnPjHTSj-- --yWzNa85KmMP80QE8KbfIF7WIUgnXEnctR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGlBAEBCgCPFiEEl3UFnzoh3OFr5PuuIjmn6PWFIFIFAlpZ/y1fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 NzUwNTlGM0EyMURDRTE2QkU0RkJBRTIyMzlBN0U4RjU4NTIwNTIRHGZsb0BnZWVr cGxhY2UuZXUACgkQIjmn6PWFIFK2Pgf/Ti7aLUnMp6LPI0bUFVLrGHmWo1hIqgIF y7B+5BkwyFN8nc4Et2/0AE+CWfl8Ud7DiGhOFtm9WletKJFju3ZFHxl0YKkcszvU dj+9lrHR8pEZqV8aVHXZ9BW4wKnjjqMN7Dt0gdzvHUqdrOjasSNDFsITThDR7rOj /d5aUzRD9P8I4BRdCPsTyNaar5i+T/oGAgHhJlzpm55hZI/93mZ+r/Zewd4zPw8l Q/iw+SUHFiUg2EfQDWLEMS5aqWlevlFMYlMxkSqra6Xdv6UaM485OXGvkfjMn6ZL QmJ29NFy/xvKm63lNlKGzKypRI5+K8moEYoTVPkoaillhW2FO2Zl5A== =SBdq -----END PGP SIGNATURE----- --yWzNa85KmMP80QE8KbfIF7WIUgnXEnctR-- From nobody Sun Jan 21 18:27:35 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A91126C19 for ; Sun, 21 Jan 2018 18:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 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_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 gJrXwJdXLhCw for ; Sun, 21 Jan 2018 18:27:31 -0800 (PST) Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (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 C65FB1200F1 for ; Sun, 21 Jan 2018 18:27:31 -0800 (PST) Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w0M2RAl5102056; Mon, 22 Jan 2018 02:27:30 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2017-10-26; bh=XFNC72FNtPE3tS7ag84IGaML8Q9oTXpiHW+w3DEc+B0=; b=rPhOLmNjuXZe+Q1dMZFDQwhK9d01bxkCtB1rPlVamoUTikPp8edDfyPWP+af2mgNiJs3 TECOfSN43/mTO/CTxyeS+uI/QDulWgBe8SsbVNw4st9oFC+XIkyS0kdMRVgLHefnz7hg 5AUZdtaomub+tZNM4Psq6B70rT5rXYpz4T2mqk5Q3DShRRFLl+4JjhHNq9Nin9QunZGF 4ScIo5eyNeNva3xkowhMiok83hwl6BCiCKcHrqKBAbQVU/FCmFrYUfXkZObmTk1OuUdM G3cl0tEUTHsGcJk9kCDHuNzoA1RJd2lIdYt5S1FGq6ZibnYa/Xcnvsn3c0wNTEmCTvH2 /g== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2130.oracle.com with ESMTP id 2fn5d985hv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Jan 2018 02:27:30 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w0M2RURe021597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 22 Jan 2018 02:27:30 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w0M2RUcZ014038; Mon, 22 Jan 2018 02:27:30 GMT Received: from [192.168.1.101] (/124.64.242.223) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 21 Jan 2018 18:27:30 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Weijun Wang In-Reply-To: <013AE0DE-06E9-42F8-98CD-BB70686A5494@oracle.com> Date: Mon, 22 Jan 2018 10:27:26 +0800 Cc: kitten Content-Transfer-Encoding: quoted-printable Message-Id: <291EE68D-BC5B-4D67-8368-B5DD78B25516@oracle.com> References: <151493583156.30989.1076207750886953383@ietfa.amsl.com> <20180103013808.GG50827@kduck.kaduk.org> <25d5a1bb-e7bb-431b-6632-09904a581d77@joelhalpern.com> <074DA813-1E7F-4C03-AEEE-5D76E8804C31@oracle.com> <41bbbe7d-0f35-78ad-a5cd-673488f3ac09@joelhalpern.com> <20180103030817.GH50827@kduck.kaduk.org> <20180103172640.GI50827@kduck.kaduk.org> <013AE0DE-06E9-42F8-98CD-BB70686A5494@oracle.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.5.20) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8781 signatures=668655 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=801 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801220031 Archived-At: Subject: Re: [kitten] draft-ietf-kitten-rfc5653bis-07 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 02:27:34 -0000 Ping agin. If you don't have any comment, I'll post a -08 I-D draft. Thanks Max > On Jan 4, 2018, at 11:41 PM, Weijun Wang = wrote: >=20 > Hi Ben >=20 > I've posted a new draft at >=20 > = http://cr.openjdk.java.net/~weijun/rfc5653bis/draft-ietf-kitten-rfc5653bis= -07.html >=20 > The only changes since -06 are: >=20 > 1. Newly added "2. Notational Conventions". >=20 > 2. Convert some of the keywords to UPPERCASE. >=20 > For every occurrence of the keywords, I've marked the UPPERCASE ones = red and lowercase ones gray so you can easily spot them. Line numbers = are added to the text. >=20 > I converted most "must" and "should" to UPPERCASE. There are many = "may"s. For those having a subject of "mechanism" or "application", I = usually leave them in lowercase. For "implementation", I usually change = it to UPPERCASE. >=20 > Please take a review. I generated this HTML from the output of = "xml2rfc --raw". The "xml2rfc --html" looks too modern for me. If you = know a way to generate an HTML like https://tools.ietf.org/html/rfc5653 = which has a plain text layout while containing links I'll be happy to = create my page based on it. >=20 > Thanks > Weijun From nobody Tue Jan 23 11:04:07 2018 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E61128954; Tue, 23 Jan 2018 11:04:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-kitten-rfc5653bis@ietf.org, mrogers@redhat.com, kitten-chairs@ietf.org, mrogers@redhat.com, kitten@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151673424092.13966.12449617359733383793.idtracker@ietfa.amsl.com> Date: Tue, 23 Jan 2018 11:04:00 -0800 Archived-At: Subject: [kitten] Alissa Cooper's Discuss on draft-ietf-kitten-rfc5653bis-06: (with DISCUSS) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 19:04:01 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-kitten-rfc5653bis-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-kitten-rfc5653bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is more for the shepherding AD than the authors/WG: in the discussion resulting from the Gen-ART review the author indicated that there would be another pass through the document to capitalize uses of normative must/should and add a reference to RFC 8174. That seems like the kind of thing where the WG should get another look at the changes to make sure everyone agrees on what the normative requirements were/are. Is that the plan? From nobody Tue Jan 23 11:05:51 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F201271DF; Tue, 23 Jan 2018 11:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=Ase2A85y; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dgVtpzIr 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 5z1oE4073c2V; Tue, 23 Jan 2018 11:05:48 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 163001289B0; Tue, 23 Jan 2018 11:05:48 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 0FA8E20A80; Tue, 23 Jan 2018 14:05:47 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Tue, 23 Jan 2018 14:05:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=rCQLRzQl+a1NpAUCROlele7QH3I9H JMzZ2VyGejDPas=; b=Ase2A85yO8qWjO+cecuOMjSsucxEVHzEOTOzDloSsAwFv Y/In9B1WlRwm+qgri3mY9hSuvTxJ1Oj4YbP8kQIeOg5cnv/9kGPyl21dK1k4LQ9o 1TBjKLbU4gwIkHc0g0IIEtZvrHmEGN01RgXySBzCj9YT28Ix7ONhBizri3IlCI/u iuYEYat0NhXJyCkhYvEwsILyqxlg+gYptXgqiRb38z1/87qqkMc1640Ytuboz3Xb eySm4KfQstm4/IAETRiH79JlvzcnKTeODF+5mokx4VqK9fhHjl2fnZUjmS8EcaXv tXSWBOYYSC93NQRVB6tim+eOCHRhUUX94OlHvRDLw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=rCQLRz Ql+a1NpAUCROlele7QH3I9HJMzZ2VyGejDPas=; b=dgVtpzIrgbvJBq+jC/c9ZO 87sy/Q5t21pFlDQzY6BWgBImM0u8xqfDG54+TzML++wDcy3RVA4+IXvrrtrTa5DJ sFyF/cmwJLLFe84UpbzZT9pLF5aEwnMp2Mmjnst+tLTJQDSYpeSOcV2+RiVnvno7 w/YdD+7fHD1PXAZWN70Zjq0WglqmtgQ7+1ybA7YghkemyTZQQEefGi2soshpbuJC +c+tXMHCd+99hmpfNnNMlprmFVo1pBCmW6HUkILrJ7BDNkiwxSlk64HyD3vPI2FN gA/3fjf5M0G9/mkoYmgQyEdYjZ/NzvKKAPBzXRRAab34IEwKS27ooXfCHlieFrdQ == X-ME-Sender: Received: from rtp-vpn1-764.cisco.com (unknown [173.38.117.79]) by mail.messagingengine.com (Postfix) with ESMTPA id 7150A7E1BE; Tue, 23 Jan 2018 14:05:46 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: Date: Tue, 23 Jan 2018 14:05:44 -0500 Cc: Benjamin Kaduk , kitten , gen-art , draft-ietf-kitten-rfc5653bis.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <19F5D23D-3677-41C6-B504-454C7595FF1F@cooperw.in> References: <151493583156.30989.1076207750886953383@ietfa.amsl.com> <20180103013808.GG50827@kduck.kaduk.org> <25d5a1bb-e7bb-431b-6632-09904a581d77@joelhalpern.com> <074DA813-1E7F-4C03-AEEE-5D76E8804C31@oracle.com> <41bbbe7d-0f35-78ad-a5cd-673488f3ac09@joelhalpern.com> <20180103030817.GH50827@kduck.kaduk.org> To: Weijun Wang , "Joel M. Halpern" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [kitten] [Gen-art] Genart telechat review of draft-ietf-kitten-rfc5653bis-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 19:05:50 -0000 Joel, thanks for your review. I think the WG will need to review the = changes to make sure people agree with which keywords become = capitalized. I=E2=80=99m holding a DISCUSS about that. Alissa > On Jan 2, 2018, at 10:48 PM, Weijun Wang = wrote: >=20 > Thanks for the suggestion. I'll go through the doc and post another = version. >=20 > --Weijun >=20 >> On Jan 3, 2018, at 11:08 AM, Benjamin Kaduk wrote: >>=20 >> I am inclined to agree that it is better to change the right ones to >> upper case -- we really don't have a good reason to still be >> producing documents with this type of ambiguity anymore. >>=20 >> Once that is done we can decide whether the change is >> substantial enough to require re-running the last call. >>=20 >> -Ben >>=20 >> On Tue, Jan 02, 2018 at 09:50:19PM -0500, Joel M. Halpern wrote: >>> Personal opinion: >>> Given that to my reading "must" is used on the document in both the = RFC=20 >>> 2119 sense and in a conventional English language sense, it would be=20= >>> worth clarifying the intention. As such, I think it would be better = to=20 >>> use the 8174 reference and go through changing the right ones to = upper case. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 1/2/18 9:40 PM, Weijun Wang wrote: >>>> Hi Joel and Ben >>>>=20 >>>> Author here. >>>>=20 >>>> I think I've removed the section because in fact none of the = keywords appears as capitalized inside the original document. In fact, = RFC 8174 has "that only UPPERCASE usage of the key words have the = defined special meanings". >>>>=20 >>>> I assume I'll need to go through the document and make some = UPPERCASE and some not, depending on the actual meanings. >>>>=20 >>>> Or, since this is a bis and changing the cases would be considered = an re-intepretation of the whole document (which wasn't my goal), is it = more reasonable to keep using RFC 2119 and leave all "must" and = "required" in lowercase? >>>>=20 >>>> Thanks >>>> Weijun >>>>=20 >>>>=20 >>>>> On Jan 3, 2018, at 9:49 AM, Joel M. Halpern = wrote: >>>>>=20 >>>>> Thanks Ben. That would be good. >>>>> Yours, >>>>> Joel >>>>>=20 >>>>> On 1/2/18 8:38 PM, Benjamin Kaduk wrote: >>>>>> Hi Joel, >>>>>> On Tue, Jan 02, 2018 at 03:30:31PM -0800, Joel Halpern wrote: >>>>>>> Reviewer: Joel Halpern >>>>>>> Review result: Ready with Issues >>>>>>>=20 >>>>>>> I am the assigned Gen-ART reviewer for this draft. The General = Area >>>>>>> Review Team (Gen-ART) reviews all IETF documents being processed >>>>>>> by the IESG for the IETF Chair. Please wait for direction from = your >>>>>>> document shepherd or AD before posting a new version of the = draft. >>>>>>>=20 >>>>>>> For more information, please see the FAQ at >>>>>>>=20 >>>>>>> . >>>>>>>=20 >>>>>>> Document: draft-ietf-kitten-rfc5653bis-06 >>>>>>> Reviewer: Joel Halpern >>>>>>> Review Date: 2018-01-02 >>>>>>> IETF LC End Date: 2017-09-11 >>>>>>> IESG Telechat date: 2018-01-25 >>>>>>>=20 >>>>>>> Summary: This document is ready for publication as a Proposed = Standard RFC >>>>>>>=20 >>>>>>> Major issues: None >>>>>>>=20 >>>>>>> Minor issues: >>>>>>> Although ID-Nits does not complain about it, I can find no = reference to >>>>>>> RFCs 2119 or 8174. Some of the uses of "must" int he = document are along >>>>>>> the lines of "inherently follows", which is not normative = language. But >>>>>>> other uses are clearly normative in structure. It is = unclear why the >>>>>>> reference to RFC 2119 was removed as part of this update. >>>>>> Thanks for the review -- I'm a bit surprised that id-nits does = not >>>>>> complain about the omission. >>>>>> I do not know why the -00 dropped that clause, but it does seem = like >>>>>> the current normal text citing 8174 should be added before >>>>>> publication. >>>>>> -Ben >>>>=20 >>>>=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Tue Jan 23 11:07:47 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F4B1271DF; Tue, 23 Jan 2018 11:07:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 jq1ccC5tGVFJ; Tue, 23 Jan 2018 11:07:39 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 AD870129C6B; Tue, 23 Jan 2018 11:07:29 -0800 (PST) X-AuditID: 12074425-999ff70000004768-ee-5a6787eec398 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 11.0B.18280.FE7876A5; Tue, 23 Jan 2018 14:07:27 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w0NJ7LBk010530; Tue, 23 Jan 2018 14:07:23 -0500 Received: from mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w0NJ7HKN018247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Jan 2018 14:07:19 -0500 Date: Tue, 23 Jan 2018 13:07:17 -0600 From: Benjamin Kaduk To: Alissa Cooper Cc: The IESG , draft-ietf-kitten-rfc5653bis@ietf.org, mrogers@redhat.com, kitten-chairs@ietf.org, kitten@ietf.org Message-ID: <20180123190716.GA93961@mit.edu> References: <151673424092.13966.12449617359733383793.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <151673424092.13966.12449617359733383793.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsUixG6nrvu+PT3K4OlLC4vpZ/4yWnw/eZTF YsaficwW13bvZ7U4unkVi8X9iXEObB5fnrxk8liy5CeTx/t9V9kCmKO4bFJSczLLUov07RK4 MpY9XsdWcJinYsfbJYwNjJu4uhg5OSQETCT6G6axdzFycQgJLGaSmPF0OhuEs5FR4uXziawQ zlkmicknNzOCtLAIqEpMOr+RDcRmE1CRaOi+zAxiiwDFrx77AdbNLNDJKDF/fTsrSEJYIFLi 39e7YA28AjoSq/d2gNlCAn4SE+f0MULEBSVOznzCAmIzC2hJ3Pj3kqmLkQPIlpZY/o8DJMwp 4C/xs3UKWLmogLLE3r5D7BMYBWYh6Z6FpHsWQvcCRuZVjLIpuVW6uYmZOcWpybrFyYl5ealF uhZ6uZkleqkppZsYwYHtorqDcc5fr0OMAhyMSjy8NyzSo4RYE8uKK3MPMUpyMCmJ8mbzA4X4 kvJTKjMSizPii0pzUosPMUpwMCuJ8OaxAuV4UxIrq1KL8mFS0hwsSuK8HibaUUIC6Yklqdmp qQWpRTBZGQ4OJQnee21AjYJFqempFWmZOSUIaSYOTpDhPEDD74LU8BYXJOYWZ6ZD5E8x6nLc ePG6jVmIJS8/L1VKnHciSJEASFFGaR7cHFBCksjeX/OKURzoLWFePmB6EuIBJjO4Sa+AljAB LblRkwqypCQRISXVwMhzeppr6pzt0Q8eJcuxTLKXmiC2Ocyi49yCJ4KZ64+7iib+WOvOwv/j 5zM7sfeC/Lsm2UvE+tYdLOmQvb815fs5bZ7ipJfCAYf95/O4r1z2qfGAl+OaHcbbpARSz+tm hLPbpc2N4E44pdrZsO18zb/SpWdqvQ7+1/h8Ys+iZWV+Qne/bF4vn6zEUpyRaKjFXFScCAC4 dQBpIwMAAA== Archived-At: Subject: Re: [kitten] Alissa Cooper's Discuss on draft-ietf-kitten-rfc5653bis-06: (with DISCUSS) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 19:07:41 -0000 On Tue, Jan 23, 2018 at 11:04:00AM -0800, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-kitten-rfc5653bis-06: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-kitten-rfc5653bis/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This is more for the shepherding AD than the authors/WG: in the discussion > resulting from the Gen-ART review the author indicated that there would be > another pass through the document to capitalize uses of normative must/should > and add a reference to RFC 8174. That seems like the kind of thing where the WG > should get another look at the changes to make sure everyone agrees on what the > normative requirements were/are. Is that the plan? The changes have been made (http://cr.openjdk.java.net/~weijun/rfc5653bis/draft-ietf-kitten-rfc5653bis-07.html) and the WG has been asked for comments. None have been received yet, though I do plan to review them this week. -Ben (with hat: chair, though I may need to reclaim the shepherd hat as well) From nobody Tue Jan 23 15:48:52 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3EB012D876; Tue, 23 Jan 2018 15:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 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_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 x6hM4nmtH6e8; Tue, 23 Jan 2018 15:48:49 -0800 (PST) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 4F6EA12D811; Tue, 23 Jan 2018 15:48:49 -0800 (PST) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w0NNfiwU170741; Tue, 23 Jan 2018 23:48:44 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2017-10-26; bh=HENPXcmFW4Za/1NMP77KuhcbNLY+ya7IQwWx/nYn7L0=; b=H/NzJvb3etndvJ7PEeqyFPLMgHg6lpe8PxN4JwoZI4erydWIQ6LTdhniW+vxWAVrpaem epR5N089qatcgoJVxEV2mEb8LJdYOVryJqge6+VJ0T5Vm559TaPXHaNanPPg5vmLTWV3 8EodhpW2WcXYj5j+7jkaK/pEeao9SDa4wrcudhH3Xpo9OuovPaSfx0FBrkR5OxGBjNb+ ou76NtOzAmLTOP7sIIg+BJVrYgT1AIIbYalrqzBuaZKJ1qbgVlOtTkhsZFgw7Ik5eXbq +czkKGy0nl2RhFKM4knvltiqVT873iGgXbnXx2aN3xMI1Ihdi0IEaXWQI4GaXkQL5fpG Ug== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2120.oracle.com with ESMTP id 2fpesur3xy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 23 Jan 2018 23:48:43 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w0NNhSrW005983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 23 Jan 2018 23:43:29 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w0NNhR4g010956; Tue, 23 Jan 2018 23:43:28 GMT Received: from [192.168.1.101] (/124.64.242.223) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 23 Jan 2018 15:43:27 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Weijun Wang In-Reply-To: <19F5D23D-3677-41C6-B504-454C7595FF1F@cooperw.in> Date: Wed, 24 Jan 2018 07:43:22 +0800 Cc: "Joel M. Halpern" , Benjamin Kaduk , kitten , gen-art , draft-ietf-kitten-rfc5653bis.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <151493583156.30989.1076207750886953383@ietfa.amsl.com> <20180103013808.GG50827@kduck.kaduk.org> <25d5a1bb-e7bb-431b-6632-09904a581d77@joelhalpern.com> <074DA813-1E7F-4C03-AEEE-5D76E8804C31@oracle.com> <41bbbe7d-0f35-78ad-a5cd-673488f3ac09@joelhalpern.com> <20180103030817.GH50827@kduck.kaduk.org> <19F5D23D-3677-41C6-B504-454C7595FF1F@cooperw.in> To: Alissa Cooper X-Mailer: Apple Mail (2.3445.5.20) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8783 signatures=668655 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=8 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801230303 Archived-At: Subject: Re: [kitten] [Gen-art] Genart telechat review of draft-ietf-kitten-rfc5653bis-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 23:48:52 -0000 I've uploaded an updated version at = http://cr.openjdk.java.net/~weijun/rfc5653bis/draft-ietf-kitten-rfc5653bis= -07.html before submitting a new I-D draft. This page shows all keywords in color = (gray for lowercase, red for uppercase), hopefully this will be easy for = everyone to review. Thanks Weijun > On Jan 24, 2018, at 3:05 AM, Alissa Cooper wrote: >=20 > Joel, thanks for your review. I think the WG will need to review the = changes to make sure people agree with which keywords become = capitalized. I=E2=80=99m holding a DISCUSS about that. >=20 > Alissa >=20 >> On Jan 2, 2018, at 10:48 PM, Weijun Wang = wrote: >>=20 >> Thanks for the suggestion. I'll go through the doc and post another = version. >>=20 >> --Weijun >>=20 >>> On Jan 3, 2018, at 11:08 AM, Benjamin Kaduk wrote: >>>=20 >>> I am inclined to agree that it is better to change the right ones to >>> upper case -- we really don't have a good reason to still be >>> producing documents with this type of ambiguity anymore. >>>=20 >>> Once that is done we can decide whether the change is >>> substantial enough to require re-running the last call. >>>=20 >>> -Ben >>>=20 >>> On Tue, Jan 02, 2018 at 09:50:19PM -0500, Joel M. Halpern wrote: >>>> Personal opinion: >>>> Given that to my reading "must" is used on the document in both the = RFC=20 >>>> 2119 sense and in a conventional English language sense, it would = be=20 >>>> worth clarifying the intention. As such, I think it would be = better to=20 >>>> use the 8174 reference and go through changing the right ones to = upper case. >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>> On 1/2/18 9:40 PM, Weijun Wang wrote: >>>>> Hi Joel and Ben >>>>>=20 >>>>> Author here. >>>>>=20 >>>>> I think I've removed the section because in fact none of the = keywords appears as capitalized inside the original document. In fact, = RFC 8174 has "that only UPPERCASE usage of the key words have the = defined special meanings". >>>>>=20 >>>>> I assume I'll need to go through the document and make some = UPPERCASE and some not, depending on the actual meanings. >>>>>=20 >>>>> Or, since this is a bis and changing the cases would be considered = an re-intepretation of the whole document (which wasn't my goal), is it = more reasonable to keep using RFC 2119 and leave all "must" and = "required" in lowercase? >>>>>=20 >>>>> Thanks >>>>> Weijun >>>>>=20 >>>>>=20 >>>>>> On Jan 3, 2018, at 9:49 AM, Joel M. Halpern = wrote: >>>>>>=20 >>>>>> Thanks Ben. That would be good. >>>>>> Yours, >>>>>> Joel >>>>>>=20 >>>>>> On 1/2/18 8:38 PM, Benjamin Kaduk wrote: >>>>>>> Hi Joel, >>>>>>> On Tue, Jan 02, 2018 at 03:30:31PM -0800, Joel Halpern wrote: >>>>>>>> Reviewer: Joel Halpern >>>>>>>> Review result: Ready with Issues >>>>>>>>=20 >>>>>>>> I am the assigned Gen-ART reviewer for this draft. The General = Area >>>>>>>> Review Team (Gen-ART) reviews all IETF documents being = processed >>>>>>>> by the IESG for the IETF Chair. Please wait for direction from = your >>>>>>>> document shepherd or AD before posting a new version of the = draft. >>>>>>>>=20 >>>>>>>> For more information, please see the FAQ at >>>>>>>>=20 >>>>>>>> . >>>>>>>>=20 >>>>>>>> Document: draft-ietf-kitten-rfc5653bis-06 >>>>>>>> Reviewer: Joel Halpern >>>>>>>> Review Date: 2018-01-02 >>>>>>>> IETF LC End Date: 2017-09-11 >>>>>>>> IESG Telechat date: 2018-01-25 >>>>>>>>=20 >>>>>>>> Summary: This document is ready for publication as a Proposed = Standard RFC >>>>>>>>=20 >>>>>>>> Major issues: None >>>>>>>>=20 >>>>>>>> Minor issues: >>>>>>>> Although ID-Nits does not complain about it, I can find no = reference to >>>>>>>> RFCs 2119 or 8174. Some of the uses of "must" int he = document are along >>>>>>>> the lines of "inherently follows", which is not normative = language. But >>>>>>>> other uses are clearly normative in structure. It is = unclear why the >>>>>>>> reference to RFC 2119 was removed as part of this update. >>>>>>> Thanks for the review -- I'm a bit surprised that id-nits does = not >>>>>>> complain about the omission. >>>>>>> I do not know why the -00 dropped that clause, but it does seem = like >>>>>>> the current normal text citing 8174 should be added before >>>>>>> publication. >>>>>>> -Ben >>>>>=20 >>>>>=20 >>=20 >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art From nobody Tue Jan 23 18:25:32 2018 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E36B12D775; Tue, 23 Jan 2018 18:25:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-kitten-rfc5653bis@ietf.org, mrogers@redhat.com, kitten-chairs@ietf.org, mrogers@redhat.com, kitten@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151676073161.24116.17270275304748635870.idtracker@ietfa.amsl.com> Date: Tue, 23 Jan 2018 18:25:31 -0800 Archived-At: Subject: [kitten] Ben Campbell's No Objection on draft-ietf-kitten-rfc5653bis-06: (with COMMENT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 02:25:32 -0000 Ben Campbell has entered the following ballot position for draft-ietf-kitten-rfc5653bis-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-kitten-rfc5653bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Alissa's discuss position. 5653 had the 2119 boilerplate, but no upper-case keywords. IIUC, the authors removed the boilerplate because of that. But keep in mind moving to the 8174 boilerplate is not a drop-in replacement. From nobody Wed Jan 24 06:18:34 2018 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A4812422F; Wed, 24 Jan 2018 06:18:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-kitten-rfc5653bis@ietf.org, mrogers@redhat.com, kitten-chairs@ietf.org, mrogers@redhat.com, kitten@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151680350853.8075.12431997984021349243.idtracker@ietfa.amsl.com> Date: Wed, 24 Jan 2018 06:18:28 -0800 Archived-At: Subject: [kitten] Alissa Cooper's No Objection on draft-ietf-kitten-rfc5653bis-06: (with COMMENT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 14:18:28 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-kitten-rfc5653bis-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-kitten-rfc5653bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for answering my DISCUSS question. From nobody Wed Jan 24 11:33:35 2018 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 967291271DF; Wed, 24 Jan 2018 11:33:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: kitten@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151682241355.22629.3066151046901682953@ietfa.amsl.com> Date: Wed, 24 Jan 2018 11:33:33 -0800 Archived-At: Subject: [kitten] I-D Action: draft-ietf-kitten-krb-spake-preauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 19:33:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation WG of the IETF. Title : SPAKE Pre-Authentication Authors : Nathaniel McCallum Simo Sorce Robbie Harwood Greg Hudson Filename : draft-ietf-kitten-krb-spake-preauth-04.txt Pages : 31 Date : 2018-01-24 Abstract: This document defines a new pre-authentication mechanism for the Kerberos protocol that uses a password authenticated key exchange. This document has three goals. First, increase the security of Kerberos pre-authentication exchanges by making offline brute-force attacks infeasible. Second, enable the use of second factor authentication without relying on FAST. This is achieved using the existing trust relationship established by the shared first factor. Third, make Kerberos pre-authentication more resilient against time synchronization errors by removing the need to transfer an encrypted timestamp from the client. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-krb-spake-preauth/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-kitten-krb-spake-preauth-04 https://datatracker.ietf.org/doc/html/draft-ietf-kitten-krb-spake-preauth-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-krb-spake-preauth-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 25 02:35:53 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25133126CBF for ; Thu, 25 Jan 2018 02:35:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net 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 GoFeAVwWNXs7 for ; Thu, 25 Jan 2018 02:35:50 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 EEA5812D82C for ; Thu, 25 Jan 2018 02:35:49 -0800 (PST) Received: by mail-lf0-x22a.google.com with SMTP id 63so2837895lfv.4 for ; Thu, 25 Jan 2018 02:35:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:from:date:message-id:subject:to; bh=d+hPad3ZJ2KTJYTxO+7q4hv+POeK8DIgCCFN5ITpvdw=; b=HEpiOHorxOI6E2s4nn/bUYHtZaIklnBzhZuhQYa7/YVywAqca27OsHgEgD9Nh1YeRd 55nJTrJM08JG5Rr56H08WlhrTpuJdu8n80rlL5Lh662m6Rrib+gqwEDuaISmIvyEsuQ6 5RASeJH0C0EHb13SL7d6kIIwo2cQScUoUX25s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=d+hPad3ZJ2KTJYTxO+7q4hv+POeK8DIgCCFN5ITpvdw=; b=dDXpsjMvlbSPpDS4UEmhZh5W7RoZNhyuUlehXIxzft6bRBhA85gT+n+VFj2ycs3GWr hOj2lLERXbEWyXMe8+0GW7ga16boQMNuOFJm//IQ1lcOsOLrkvavPxGwyyBWNpT4Q+8e vYfqDo9RUr6a4w/Oqbi9dVQYrUcg9lx+WDsxCh3E8ujx0lF1GLO47z1kcdNCYWHBXJpP ZE9d7r1Doi9t9cS9pw1yzcTqP+Ng0Yb7GoiyHf9dVAy2tv8TCHGWhZM6FsnCyvpa+lit y4XzGg4ii3XuheDlPjxDNAfyPEtTUHEfodH8s1eSPxO4AcigXRF0O4XnYis2/WYENbVj uJ/g== X-Gm-Message-State: AKwxyteInOwVfksXM0WaLA/2Ty3V92Tjfp/pk+Zk+O4MQl9sM8kTp0YB 4LU+qxQ6k4pt431rtZ0t1hUpssT4CHqI4mQOF5aDccLS X-Google-Smtp-Source: AH8x227NT5NW+zYEYUx0hbwhN6oVIYhHlid6NLbSJmSTYczbSWzhdW93bndmJnm5Gq97sMt3FeGEGCNJ1h58eDd7Wzo= X-Received: by 10.46.53.18 with SMTP id z18mr5820256ljz.4.1516876547889; Thu, 25 Jan 2018 02:35:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.179.26.7 with HTTP; Thu, 25 Jan 2018 02:35:47 -0800 (PST) From: Dave Cridland Date: Thu, 25 Jan 2018 10:35:47 +0000 Message-ID: To: kitten@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [kitten] TOTP in SASL in XMPP X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 10:35:52 -0000 Dear Kittens, A new ball of wool to play with: I've been working with my colleagues over the past few months trying to get a working TOTP pattern for XMPP. Initial publication of all the bits has just finished, so it's a good time to nudge the list and say how keen I am to find out what I've done wrong. The basic requirements are roughly the following: 1) Users can be made to enter a TOTP code as part of the login flow. 2) This can be a single movable part (ie, no OAUTH/SAML). 3) Users can request to "remember this browser". 4) Threat model assumes that at some point, devices will be stolen, server databases exfiltrated, and credentials lifted from clients. We've tried to address this by a bunch of specifications, one Internet Draft and the rest XEPs over at the XSF: * XEP-0388 provides an enhanced SASL profile for XMPP which introduces a new quasi-terminal response of "continue", which is functionally identical to "success", except it demands further action by the client in the form of "tasks". * XEP-0400 provides a TOTP task, as well as some application-level stuff in XMPP to handle provisioning. * draft-cridland-kitten-clientkey provides a per-client, 1*RTT SASL mechanism which we then use as the "remember this device". * XEP-0399 then implements the application-level stuff in XMPP for CLIENT-KEY, which handles provisioning etc. These four build into a functioning and usable TOTP implementation. As I say, I would welcome feedback. There is a strong coupling between draft-cridland-kitten-clientkey and XEP-0399, but otherwise each part is weakly coupled and can be replaced (so if we want a DH-based mechanism instead of - or as well as - CLIENT-KEY's hash-and-counter, that's easily done). We (Surevine) have a working implementation of this, except that we're currently using an older, weaker, design instead of CLIENT-KEY. Dave. From nobody Thu Jan 25 10:51:44 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91DE1273B1 for ; Thu, 25 Jan 2018 10:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.04 X-Spam-Level: * X-Spam-Status: No, score=1.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_SOFTFAIL=0.665, TO_NO_BRKTS_DYNIP=1.293] autolearn=no autolearn_force=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 uXratlnStvO0 for ; Thu, 25 Jan 2018 10:51:41 -0800 (PST) Received: from mail.suchdamage.org (ec2-52-9-186-167.us-west-1.compute.amazonaws.com [52.9.186.167]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7A2D12DB70 for ; Thu, 25 Jan 2018 10:51:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.suchdamage.org (Postfix) with ESMTP id ADB48296B2 for ; Thu, 25 Jan 2018 13:51:41 -0500 (EST) Received: from mail.suchdamage.org ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vq9QcnL7PKJ for ; Thu, 25 Jan 2018 13:51:41 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (c-174-63-86-215.hsd1.ma.comcast.net [174.63.86.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) (Authenticated sender: hartmans-laptop) by mail.suchdamage.org (Postfix) with ESMTPSA for ; Thu, 25 Jan 2018 13:51:41 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id AE07AC0BAC; Thu, 25 Jan 2018 13:51:39 -0500 (EST) From: Sam Hartman To: kitten@ietf.org Date: Thu, 25 Jan 2018 13:51:39 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [kitten] Concerns about draft-ietf-kitten-krb-spake-preauth-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 18:51:43 -0000 Hi. I came across the SPAKE preauthentication draft because IANA asked me to look at it. I was late and they sent it along to Larry before I could get around to it. I like the general approach. I ran into two specific issues, and only conducted a brief review of the document. I support having a solution to something along these lines, but I suspect we're a few revisions away from something solid here. I have two initial concerns. First, the draft claims to provide the strengthen reply key facility. However as far as I can tell from section 8, the draft entirely replaces the reply key. The strengthen reply key facility is only appropriate if the original reply key is mixed into the resulting reply key. This is important because after the reply key has been replaced, knowledge of the reply key does not imply anything about authentication. I believe this mechanism provides the replace reply key facility not the strengthen reply key facility. I also have concerns about the proposal to make Kerberos checksums deterministic. Permitting non-deterministic checksums was an intentional decision during the development of RFC 3961. The theoretical basis behind deterministic checksums is dubious at best; there are a lot safer models for non-deterministic checksums just as there are better theoretical (and practical) models behind non-deterministic encription. During the SHA-3 competition, there was discussion of whether NIST should look at parameterized/non-deterministic hashing. The conclusion was not to do so, but at least none of the discussions I saw seemed to deny the value of non-deterministic hashing. We revisited this decision yet again when we drafted RFC 6113, and ran into exactly the same issue that I think drove the authors to want to change Kerberos checksums: the desire to create an incremental checksum of the conversation in a manner similar to TLS. After careful discussion, we abandoned that approach. It would forbid non-deterministic checksums and would require exporting partial checksum contexts in KDC cookies. Even if we're going to revisit that decision again, this document is not the appropriate place to do so. That's a significant change to RFC 3961 and an explicit reversal of a decision that has been reviewed within the community multiple times. Such a change should be in its own standards track document not combined with this specification. Beyond these specific concerns, I'm nervous about the alignment of this spec and RFC 6113. Doubtless part of that is my involvement in 6113 speaking, and I certainly don't have anything substantiated. I would request others review for alignment with 6113. I expect to fully review the document within the next week. --Sam From nobody Thu Jan 25 12:07:31 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F53E12EA93 for ; Thu, 25 Jan 2018 12:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 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, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 bmqnuNuFx9Ki for ; Thu, 25 Jan 2018 12:07:26 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 247A112EA7C for ; Thu, 25 Jan 2018 12:07:25 -0800 (PST) X-AuditID: 1209190f-f1dff70000007783-c6-5a6a38fbe4e0 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-4.mit.edu (Symantec Messaging Gateway) with SMTP id B6.31.30595.CF83A6A5; Thu, 25 Jan 2018 15:07:24 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w0PK7MnX022359; Thu, 25 Jan 2018 15:07:23 -0500 Received: from [18.101.8.200] (VPN-18-101-8-200.MIT.EDU [18.101.8.200]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w0PK7Khb019517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 Jan 2018 15:07:21 -0500 To: Sam Hartman , kitten@ietf.org References: From: Greg Hudson Message-ID: <5777908c-6752-e623-d25d-3b5b23bcbda4@mit.edu> Date: Thu, 25 Jan 2018 15:07:20 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IR4hRV1v1jkRVlMO02t8XXtgdsFkc3r2Jx YPJYsuQnk8fKqafZA5iiuGxSUnMyy1KL9O0SuDKO3o4pmClT8aTzE1sD4xTxLkZODgkBE4nf l88wdjFycQgJLGaSeHGykQnC2cgocbrnJpRzlEmi4eUDdpAWYQFvifsf7zKB2CICFhIfNl5i BrGFBHQkVt5fzAhiswkoS6zfv5UFxOYVsJKY8W41UJyDg0VAVaL1sSpIWFQgQqJp5lxWiBJB iZMzn7CAlHAK6Er0fEoHCTMLqEv8mQcxnVlAXOLWk/lMELa8xPa3c5gnMArMQtI9C0nLLCQt s5C0LGBkWcUom5JbpZubmJlTnJqsW5ycmJeXWqRropebWaKXmlK6iREcvJL8OxjnNHgfYhTg YFTi4b1xOzNKiDWxrLgy9xCjJAeTkijvgv6MKCG+pPyUyozE4oz4otKc1OJDjBIczEoivIK6 WVFCvCmJlVWpRfkwKWkOFiVxXncT7SghgfTEktTs1NSC1CKYrAwHh5IE70tzoEbBotT01Iq0 zJwShDQTByfIcB6g4c9BaniLCxJzizPTIfKnGHU5brx43cYsxJKXn5cqJc7LA1IkAFKUUZoH NwecdFI5TrxiFAd6S5j3B0gVDzBhwU16BbSECWiJXUUmyJKSRISUVAOjR1nn/s+n9XeGb37o uzr3x2EXW5ZqJ73+s38/My7teyepH330llTltAr78ph4vqYl2Sce5Gzdouv5ku91qt2N4qUf nvnw/bfKmxnaf+nS7egqnW9FM3o2cc9K4N48Y0KefM7ZV9vvTvk39TF74PKf6y/Lzf46I/Cs 75fAX7GV4a1qTtxNYiHTlViKMxINtZiLihMBUrmpmRUDAAA= Archived-At: Subject: Re: [kitten] Concerns about draft-ietf-kitten-krb-spake-preauth-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 20:07:30 -0000 On 01/25/2018 01:51 PM, Sam Hartman wrote: > First, the draft claims to provide the strengthen reply key facility. > However as far as I can tell from section 8, the draft entirely replaces > the reply key. The strengthen reply key facility is only appropriate if > the original reply key is mixed into the resulting reply key. > This is important because after the reply key has been replaced, > knowledge of the reply key does not imply anything about authentication. > I believe this mechanism provides the replace reply key facility not the > strengthen reply key facility. The replacement key K'[0] is PRF+(initial-reply-key, stuff) where stuff includes the SPAKE shared result. Do you think that is not an adequate way of mixing in the initial reply key? > I also have concerns about the proposal to make Kerberos checksums > deterministic. Please have a look at https://www.ietf.org/mail-archive/web/kitten/current/msg06416.html and say which direction appeals to you the most. I went with this approach because it reflected WG consensus at the time, and tried to be up front about it (I sent https://www.ietf.org/mail-archive/web/kitten/current/msg06427.html with a clear subject line). > Permitting non-deterministic checksums was an intentional decision > during the development of RFC 3961. > The theoretical basis behind deterministic checksums is dubious at best; > there are a lot safer models for non-deterministic checksums just as > there are better theoretical (and practical) models behind > non-deterministic encription. We have had a deterministic checksum tightly coupled to every enctype after single-DES, and have used only those tightly-coupled checksums in standards documents for many years. We also haven't ever introduced a checksum type negotiation mechanism other than "this enctype implies this mandatory-to-implement checksum." So I don't agree with this at all; I think the value of admitting non-deterministic checksums is highly dubious, and that it's vanishingly unlikely that we would ever migrate towards non-deterministic checksums in the future. If I could go back in time, I would strongly argue for deterministic keyed checksums to be a function in the enctype profile, and for checksum types to not be a thing. Having a type registry purely for unkeyed checksums would be okay if we had a need for it. But having checksum types with different properties lumped together, in a separate registry from enctypes, is how we got CVE-2010-1324 and friends. > We revisited this decision yet again when we drafted RFC 6113, and ran > into exactly the same issue that I think drove the authors to want to > change Kerberos checksums: the desire to create an incremental checksum > of the conversation in a manner similar to TLS. > After careful discussion, we abandoned that approach. > It would forbid non-deterministic checksums and would require exporting > partial checksum contexts in KDC cookies. I do recall that an earlier iteration of 6113 would have required storing either a partial checksum context or a partial conversation transcript in the KDC cookie, but the transcript checksum mechanism in the SPAKE draft doesn't require exporting partial contexts. > Such a change should be in its own standards track document not combined > with this specification. I am a little surprised to hear that. We don't have a history of being sticklers about document scope; for example, RFC 6806 introduced PA-REQ-ENC-PA-REP and FAST negotiation, despite being primarily about referrals. From nobody Fri Jan 26 18:13:11 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC0612D876; Fri, 26 Jan 2018 18:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.229 X-Spam-Level: X-Spam-Status: No, score=-4.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 B85VP2Fxjteq; Fri, 26 Jan 2018 18:13:02 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 14AF012D86F; Fri, 26 Jan 2018 18:13:01 -0800 (PST) X-AuditID: 1209190e-90bff70000000ce3-67-5a6be02c0a6d 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 9A.3F.03299.C20EB6A5; Fri, 26 Jan 2018 21:13:00 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w0R2CxpA029135; Fri, 26 Jan 2018 21:12:59 -0500 Received: from [18.101.8.176] (VPN-18-101-8-176.MIT.EDU [18.101.8.176]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w0R2Ct2o030493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 26 Jan 2018 21:12:56 -0500 To: Weijun Wang , Alissa Cooper Cc: kitten , gen-art , "Joel M. Halpern" , draft-ietf-kitten-rfc5653bis.all@ietf.org References: <151493583156.30989.1076207750886953383@ietfa.amsl.com> <20180103013808.GG50827@kduck.kaduk.org> <25d5a1bb-e7bb-431b-6632-09904a581d77@joelhalpern.com> <074DA813-1E7F-4C03-AEEE-5D76E8804C31@oracle.com> <41bbbe7d-0f35-78ad-a5cd-673488f3ac09@joelhalpern.com> <20180103030817.GH50827@kduck.kaduk.org> <19F5D23D-3677-41C6-B504-454C7595FF1F@cooperw.in> From: Greg Hudson Message-ID: <366697b8-2a0c-243b-b153-ee8eb4358580@mit.edu> Date: Fri, 26 Jan 2018 21:12:54 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCKsWRmVeSWpSXmKPExsUixCmqravzIDvK4OBdU4vpZ/4yWiw6uo/Z 4uqrzywWH0+9YbI4unkVi8XXpRuYHdg8vjx5yeSxZMlPJo9zU74zenx8eoslgCWKyyYlNSez LLVI3y6BK+PmTe6Ch+wVz6/nNDAuYeti5OSQEDCRmPP2JXMXIxeHkMBiJolZ2/+zQDgbGSV6 ehqgnKNMEr9uz2MHaREWiJZoW3gNrF1EwFti4cEWRpAiZoF5jBLt8xdCzbrNLHFhXxcTSBWb gLLE+v1bWUBsXgEriQnnL7J2MXJwsAioSsz7Zw4SFhWIkGiaOZcVokRQ4uTMJ2DlnAJ2EhNb vjKC2MwC6hJ/5l1ihrDFJW49mc8EYctLbH87h3kCo+AsJO2zkLTMQtIyC0nLAkaWVYyyKblV urmJmTnFqcm6xcmJeXmpRbrGermZJXqpKaWbGMFRIcm3g3FSg/chRgEORiUe3gST7Cgh1sSy 4srcQ4ySHExKorwi84BCfEn5KZUZicUZ8UWlOanFhxglOJiVRHjNOIFyvCmJlVWpRfkwKWkO FiVxXncT7SghgfTEktTs1NSC1CKYrAwHh5IEL9N9oEbBotT01Iq0zJwShDQTByfIcB6g4Zvu gQwvLkjMLc5Mh8ifYjTmaFv5pI2Z48aL123MQix5+XmpUuK8bCDjBEBKM0rz4KaBE1sqx4ZX jOJAzwnzFoFU8QCTIty8V0CrmIBW2VVkgqwqSURISTUw5v6zVo49/nSGoRT7pJo3vpqB5jnW 4pFrmP9KBkv+7ha6+2Zbt51OFMO5GKcn6kc3X1zXxrdk+nG7tIBb6xRuyUikMypc2HLjkNtp 6/0i1WI/Wj85rTt5pF5RRzjyZVbU/5xLhp9uTSiWeTWjd8ndRY8UtXhOcVxu7WGLY6rd4Ca7 Q0JxskmaEktxRqKhFnNRcSIAbkZzT0cDAAA= Archived-At: Subject: Re: [kitten] [Gen-art] Genart telechat review of draft-ietf-kitten-rfc5653bis-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2018 02:13:04 -0000 On 01/23/2018 06:43 PM, Weijun Wang wrote: > I've uploaded an updated version at > > http://cr.openjdk.java.net/~weijun/rfc5653bis/draft-ietf-kitten-rfc5653bis-07.html This is a great format for reviewing these changes; thanks for generating it. Line 416 does not capitalize "optional" in "optional services", but lines 385 and 391 do. Lines 422 and 424 should probably capitalize "should". Line 429 should probably capitalize "may". At line 598, I would lean towards leaving "MUST" in lowercase as we are describing an application requirement, not prescribing one. Line 1174, I would leave "MAY" in lowercase. Line 1129, "may" should probably be capitalized. Line 1369, I would leave "MAY" alone as this seems more descriptive than prescriptive. Line 3221's use of "SHOULD" is prescriptive, but there's no other way to request the default QOP. So I would leave it lowercase (or change the wording, but I'm not trying to open any more cans of worms). From nobody Sun Jan 28 05:41:23 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F317312DA2B; Sun, 28 Jan 2018 05:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 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_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 g64mWiI2_yAH; Sun, 28 Jan 2018 05:41:15 -0800 (PST) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 3C8AB129C6D; Sun, 28 Jan 2018 05:41:15 -0800 (PST) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w0SDc4Xg064069; Sun, 28 Jan 2018 13:41:10 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2017-10-26; bh=mKsU4yaSBPwq6Bi2a2eaJAg3flFwkAJHtYIbj6wsJ9k=; b=PrW1cMxnNaSHIsW6SR2jyj0XEFfkqz2XvqKFoeD0tjvGmT8fvhQglBLrSIkoPUqK5679 9J3Ls3ta6KmV1V/vNx6laJskychhRICRBS8mWOz8mXiPgutxSjWK9okWh/3XLvs8QslW /PcvyL6LBfl0HBAMHkHgBUmLKpXjkqdyLFffWqx4xnDWN+RQ3fyyq8hEByS+Dq/V4Kzb C8btBkhcpr2g/80YNGFhW7DxBKdkGMmgybOlXcQs0CzFFaq6w/riacTu2m6hT8KrOPas HPsO9Mb2Ru7YHMY+RRwQedHEDbXx1JHCyhnGCXSl2yir5tY8mcndnzkVNgsTZ1eopAz9 yw== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2fsesvg2m0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 28 Jan 2018 13:41:10 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w0SDf9sO002937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 28 Jan 2018 13:41:09 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w0SDf8DK026668; Sun, 28 Jan 2018 13:41:08 GMT Received: from [192.168.1.101] (/114.240.102.71) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 28 Jan 2018 05:41:08 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Weijun Wang In-Reply-To: <366697b8-2a0c-243b-b153-ee8eb4358580@mit.edu> Date: Sun, 28 Jan 2018 21:41:03 +0800 Cc: Alissa Cooper , kitten , gen-art , "Joel M. Halpern" , draft-ietf-kitten-rfc5653bis.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0798B7AD-FC4A-4799-827D-BEE51A34B392@oracle.com> References: <151493583156.30989.1076207750886953383@ietfa.amsl.com> <20180103013808.GG50827@kduck.kaduk.org> <25d5a1bb-e7bb-431b-6632-09904a581d77@joelhalpern.com> <074DA813-1E7F-4C03-AEEE-5D76E8804C31@oracle.com> <41bbbe7d-0f35-78ad-a5cd-673488f3ac09@joelhalpern.com> <20180103030817.GH50827@kduck.kaduk.org> <19F5D23D-3677-41C6-B504-454C7595FF1F@cooperw.in> <366697b8-2a0c-243b-b153-ee8eb4358580@mit.edu> To: Greg Hudson X-Mailer: Apple Mail (2.3445.5.20) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8787 signatures=668655 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=9 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=610 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801280190 Archived-At: Subject: Re: [kitten] [Gen-art] Genart telechat review of draft-ietf-kitten-rfc5653bis-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 13:41:17 -0000 Hi Greg Thank you so much for your careful review. All suggestions accepted. > On Jan 27, 2018, at 10:12 AM, Greg Hudson wrote: >=20 > On 01/23/2018 06:43 PM, Weijun Wang wrote: >> I've uploaded an updated version at >>=20 >> = http://cr.openjdk.java.net/~weijun/rfc5653bis/draft-ietf-kitten-rfc5653bis= -07.html >=20 > This is a great format for reviewing these changes; thanks for > generating it. Glad you like it. I have to do this to avoid words like the 2nd MAY in = the 3rd paragraph on page 45. >=20 > Line 416 does not capitalize "optional" in "optional services", but > lines 385 and 391 do. >=20 > Lines 422 and 424 should probably capitalize "should". Line 429 = should > probably capitalize "may". >=20 > At line 598, I would lean towards leaving "MUST" in lowercase as we = are > describing an application requirement, not prescribing one. >=20 > Line 1174, I would leave "MAY" in lowercase. >=20 > Line 1129, "may" should probably be capitalized. 1179? Thanks Weijun >=20 > Line 1369, I would leave "MAY" alone as this seems more descriptive = than > prescriptive. >=20 > Line 3221's use of "SHOULD" is prescriptive, but there's no other way = to > request the default QOP. So I would leave it lowercase (or change the > wording, but I'm not trying to open any more cans of worms). >=20 From nobody Sun Jan 28 10:34:15 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB8B12FB01; Sun, 28 Jan 2018 10:34:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 Q7uqGFczIeeL; Sun, 28 Jan 2018 10:34:11 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 3A2C212FAFD; Sun, 28 Jan 2018 10:34:09 -0800 (PST) X-AuditID: 12074425-921ff70000005c85-d6-5a6e179f117b Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 10.03.23685.F971E6A5; Sun, 28 Jan 2018 13:34:08 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w0SIY5uJ018799; Sun, 28 Jan 2018 13:34:06 -0500 Received: from [18.101.8.210] (VPN-18-101-8-210.MIT.EDU [18.101.8.210]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w0SIY172002070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 28 Jan 2018 13:34:03 -0500 To: Weijun Wang Cc: Alissa Cooper , kitten , gen-art , "Joel M. Halpern" , draft-ietf-kitten-rfc5653bis.all@ietf.org References: <151493583156.30989.1076207750886953383@ietfa.amsl.com> <20180103013808.GG50827@kduck.kaduk.org> <25d5a1bb-e7bb-431b-6632-09904a581d77@joelhalpern.com> <074DA813-1E7F-4C03-AEEE-5D76E8804C31@oracle.com> <41bbbe7d-0f35-78ad-a5cd-673488f3ac09@joelhalpern.com> <20180103030817.GH50827@kduck.kaduk.org> <19F5D23D-3677-41C6-B504-454C7595FF1F@cooperw.in> <366697b8-2a0c-243b-b153-ee8eb4358580@mit.edu> <0798B7AD-FC4A-4799-827D-BEE51A34B392@oracle.com> From: Greg Hudson Message-ID: <20e99507-31d6-9844-1936-21d0508df9fb@mit.edu> Date: Sun, 28 Jan 2018 13:34:01 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <0798B7AD-FC4A-4799-827D-BEE51A34B392@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKKsWRmVeSWpSXmKPExsUixCmqrLtAPC/KoLGLx2L6mb+MFouO7mO2 uPrqM4vFx1NvmCyObl7FYvF16QZmBzaPL09eMnksWfKTyePclO+MHh+f3mIJYInisklJzcks Sy3St0vgyrhy5ANzwU3GisvPnzA3MK5m7GLk5JAQMJH4sv03WxcjF4eQwGImiWkf17NDOBsZ Jdbc2ccE4Rxlktj1bwYTSIuwQLRE28JrbCC2iICGRMODJmYQm1ngIKPE8Q2hEA0HWCQ6V/ey gCTYBJQl1u/fCmRzcPAKWElcXVcLEmYRUJW4N/EUWK+oQIRE08y5rCA2r4CgxMmZT8BaOQXs JNY3zYGary7xZ94lKFtc4taT+UwQtrzE9rdzmCcwCs5C0j4LScssJC2zkLQsYGRZxSibklul m5uYmVOcmqxbnJyYl5dapGuhl5tZopeaUrqJERQX7C6qOxjn/PU6xCjAwajEw9twPCdKiDWx rLgy9xCjJAeTkiiv45fcKCG+pPyUyozE4oz4otKc1OJDjBIczEoivDLXgXK8KYmVValF+TAp aQ4WJXFeDxPtKCGB9MSS1OzU1ILUIpisDAeHkgRvrlhelJBgUWp6akVaZk4JQpqJgxNkOA/Q cG6QGt7igsTc4sx0iPwpRmOOtpVP2pg5brx43cYsxJKXn5cqJc47A6RUAKQ0ozQPbho4taVy XHrFKA70nDBvI0gVDzAtws17BbSKCWjVilyQP4pLEhFSUg2MClkzpNa821RY63vBVUhYoTvz orDAYylvO+MO7bfy1rUXLq+utbMt/HYudsXqI78npeyqKNaZtaxhY8ehHYH7FEqVtFxNm5It pu6MiPNVsX35XbhU+NS22/p+N7S1ZB883blM7du77pmLHgT+fbjMvpWlqsDv05G1z4/x/v6z ZdGa69knOnfcUmIpzkg01GIuKk4EAI1T73ZIAwAA Archived-At: Subject: Re: [kitten] [Gen-art] Genart telechat review of draft-ietf-kitten-rfc5653bis-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 18:34:13 -0000 On 01/28/2018 08:41 AM, Weijun Wang wrote:>> Line 1129, "may" should probably be capitalized. > > 1179? No, that one looks okay. I think I must have meant line 1229: "The application may use byte arrays..." From nobody Sun Jan 28 17:06:28 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1819412D88C; Sun, 28 Jan 2018 17:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 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_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 p3_VyS1NzRGP; Sun, 28 Jan 2018 17:06:19 -0800 (PST) Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (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 DD42A1272E1; Sun, 28 Jan 2018 17:06:18 -0800 (PST) Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w0T126TE019021; Mon, 29 Jan 2018 01:06:15 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2017-10-26; bh=dxN6gte9HUPWi+aOIf7X0BbYBF8tiSCnG3BecJ9G8Xk=; b=EZ7e+Uq3wmxC8L9OSJk6DLBo6oyeA8+CA2gJWwzYxb5tLsOlF9hd5KmQTdIZF7CiNSA6 BFhp3bz677XekyvGiN6Kp9BnKJ23HCO1ZIfR/Lwjh4f4gwzPWB9c2uyTza4y8nVAjuzE zt2ngytiGgwJQ3aS47KX9+f8w/Rtx1IpScGgNQdIsiI0Eunx8gVtem6wpA53NZvTTfMN 90llHP5Wh2RWwSVdWKDYVuk3r7LYsLgfWZZ7/d5il/4zZfY1kOXKM40aCtta7fJIKsTB RbxK7u9wnt340Cof8ODFec0t1k1DutYySMmcz8WqzTi3Tbjs1aMQ3kYVZLCay4yCX5Lk eQ== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2130.oracle.com with ESMTP id 2fss4n818a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 29 Jan 2018 01:06:15 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w0T16EWB019004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 29 Jan 2018 01:06:14 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w0T16CEx013374; Mon, 29 Jan 2018 01:06:13 GMT Received: from [192.168.1.101] (/114.240.102.71) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 28 Jan 2018 17:06:12 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Weijun Wang In-Reply-To: <20e99507-31d6-9844-1936-21d0508df9fb@mit.edu> Date: Mon, 29 Jan 2018 09:06:07 +0800 Cc: Alissa Cooper , kitten , gen-art , "Joel M. Halpern" , draft-ietf-kitten-rfc5653bis.all@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <151493583156.30989.1076207750886953383@ietfa.amsl.com> <20180103013808.GG50827@kduck.kaduk.org> <25d5a1bb-e7bb-431b-6632-09904a581d77@joelhalpern.com> <074DA813-1E7F-4C03-AEEE-5D76E8804C31@oracle.com> <41bbbe7d-0f35-78ad-a5cd-673488f3ac09@joelhalpern.com> <20180103030817.GH50827@kduck.kaduk.org> <19F5D23D-3677-41C6-B504-454C7595FF1F@cooperw.in> <366697b8-2a0c-243b-b153-ee8eb4358580@mit.edu> <0798B7AD-FC4A-4799-827D-BEE51A34B392@oracle.com> <20e99507-31d6-9844-1936-21d0508df9fb@mit.edu> To: Greg Hudson X-Mailer: Apple Mail (2.3445.5.20) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8788 signatures=668655 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=8 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=962 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801290012 Archived-At: Subject: Re: [kitten] [Gen-art] Genart telechat review of draft-ietf-kitten-rfc5653bis-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 01:06:23 -0000 > On Jan 29, 2018, at 2:34 AM, Greg Hudson wrote: > > On 01/28/2018 08:41 AM, Weijun Wang wrote:>> Line 1129, "may" should > probably be capitalized. >> >> 1179? > > No, that one looks okay. I think I must have meant line 1229: "The > application may use byte arrays..." I see. Accepted. Thanks Weijun From nobody Sun Jan 28 17:28:35 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823751314CF; Sun, 28 Jan 2018 17:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 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_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 opskAc6hHUf8; Sun, 28 Jan 2018 17:28:31 -0800 (PST) Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 5D4A41314D8; Sun, 28 Jan 2018 17:28:07 -0800 (PST) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w0T1S1be070323; Mon, 29 Jan 2018 01:28:02 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2017-10-26; bh=iCJ4Gw0+zaXqHzlNKjaUNAbVKy+ZRy1qekYS7pp8iuk=; b=eG3Lu6oN8BuJvahqMPqbK52GDtKCISCAftDciQQddEif4/ffUlm4oPxK9iBHN8f35eQk ZMcoyP0hQvOyC16tcrY1XE7utCqIyQWL4KgRce39S7m/TZHEdRlduDVUjr2ny5uGtCIf 20V92PRxqsdWwRV0Z0UHf3vNP/mXP+5fXlZ/0Y5vb6bE8ljTNQRdetl0vP1U+Mnw8MJC IjHT47a4Pzjv2FU5SjKygieqyOyOXV8cu9eMrCoYHRcIHf+EHfCwQ9Va1aO2f4qqbNu5 fPkvOhdUYzRtj9BcFlJHEW55BDC6SlBhQEpWeU6H/DLlbVJFjoNyoJOZKG0anxJwhwZg 6Q== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2120.oracle.com with ESMTP id 2fsryhr325-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 29 Jan 2018 01:28:01 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w0T1QE9x002819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 29 Jan 2018 01:26:14 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w0T1QD9h020414; Mon, 29 Jan 2018 01:26:13 GMT Received: from [192.168.1.101] (/114.240.102.71) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 28 Jan 2018 17:26:12 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Weijun Wang In-Reply-To: <366697b8-2a0c-243b-b153-ee8eb4358580@mit.edu> Date: Mon, 29 Jan 2018 09:26:08 +0800 Cc: Alissa Cooper , kitten , gen-art , "Joel M. Halpern" , draft-ietf-kitten-rfc5653bis.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8F5B79CD-B928-4B8E-97FA-D946784228B7@oracle.com> References: <151493583156.30989.1076207750886953383@ietfa.amsl.com> <20180103013808.GG50827@kduck.kaduk.org> <25d5a1bb-e7bb-431b-6632-09904a581d77@joelhalpern.com> <074DA813-1E7F-4C03-AEEE-5D76E8804C31@oracle.com> <41bbbe7d-0f35-78ad-a5cd-673488f3ac09@joelhalpern.com> <20180103030817.GH50827@kduck.kaduk.org> <19F5D23D-3677-41C6-B504-454C7595FF1F@cooperw.in> <366697b8-2a0c-243b-b153-ee8eb4358580@mit.edu> To: Greg Hudson X-Mailer: Apple Mail (2.3445.5.20) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8788 signatures=668655 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=9 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=592 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801290017 Archived-At: Subject: Re: [kitten] [Gen-art] Genart telechat review of draft-ietf-kitten-rfc5653bis-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 01:28:33 -0000 The HTML file updated in place. Thanks Weijun > On Jan 27, 2018, at 10:12 AM, Greg Hudson wrote: >=20 > On 01/23/2018 06:43 PM, Weijun Wang wrote: >> I've uploaded an updated version at >>=20 >> = http://cr.openjdk.java.net/~weijun/rfc5653bis/draft-ietf-kitten-rfc5653bis= -07.html >=20 > This is a great format for reviewing these changes; thanks for > generating it. >=20 > Line 416 does not capitalize "optional" in "optional services", but > lines 385 and 391 do. >=20 > Lines 422 and 424 should probably capitalize "should". Line 429 = should > probably capitalize "may". >=20 > At line 598, I would lean towards leaving "MUST" in lowercase as we = are > describing an application requirement, not prescribing one. >=20 > Line 1174, I would leave "MAY" in lowercase. >=20 > Line 1229, "may" should probably be capitalized. >=20 > Line 1369, I would leave "MAY" alone as this seems more descriptive = than > prescriptive. >=20 > Line 3221's use of "SHOULD" is prescriptive, but there's no other way = to > request the default QOP. So I would leave it lowercase (or change the > wording, but I'm not trying to open any more cans of worms). >=20 From nobody Mon Jan 29 05:14:32 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D8512EB15 for ; Mon, 29 Jan 2018 05:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.252 X-Spam-Level: X-Spam-Status: No, score=-0.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 mTEmJGXiH0m4 for ; Mon, 29 Jan 2018 05:14:29 -0800 (PST) Received: from mail.suchdamage.org (ec2-52-9-186-167.us-west-1.compute.amazonaws.com [52.9.186.167]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F16D12D847 for ; Mon, 29 Jan 2018 05:14:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.suchdamage.org (Postfix) with ESMTP id B2EB6297B0; Mon, 29 Jan 2018 08:14:27 -0500 (EST) Received: from mail.suchdamage.org ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7YS9DahcLwJ; Mon, 29 Jan 2018 08:14:26 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (c-174-63-85-75.hsd1.ma.comcast.net [174.63.85.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) (Authenticated sender: hartmans-laptop) by mail.suchdamage.org (Postfix) with ESMTPSA; Mon, 29 Jan 2018 08:14:26 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C69FCC0782; Mon, 29 Jan 2018 08:14:24 -0500 (EST) From: Sam Hartman To: Greg Hudson Cc: Sam Hartman , kitten@ietf.org References: <5777908c-6752-e623-d25d-3b5b23bcbda4@mit.edu> Date: Mon, 29 Jan 2018 08:14:24 -0500 In-Reply-To: <5777908c-6752-e623-d25d-3b5b23bcbda4@mit.edu> (Greg Hudson's message of "Thu, 25 Jan 2018 15:07:20 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [kitten] Concerns about draft-ietf-kitten-krb-spake-preauth-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 13:14:30 -0000 >>>>> "Greg" == Greg Hudson writes: Greg> On 01/25/2018 01:51 PM, Sam Hartman wrote: >> First, the draft claims to provide the strengthen reply key >> facility. However as far as I can tell from section 8, the draft >> entirely replaces the reply key. The strengthen reply key >> facility is only appropriate if the original reply key is mixed >> into the resulting reply key. This is important because after >> the reply key has been replaced, knowledge of the reply key does >> not imply anything about authentication. I believe this >> mechanism provides the replace reply key facility not the >> strengthen reply key facility. Greg> The replacement key K'[0] is PRF+(initial-reply-key, stuff) Greg> where stuff includes the SPAKE shared result. Do you think Greg> that is not an adequate way of mixing in the initial reply Greg> key? I'm sorry, I misread the spec. We are in agreement that strengthen reply key is appropriate. >> I also have concerns about the proposal to make Kerberos >> checksums deterministic. Greg> Please have a look at Greg> https://www.ietf.org/mail-archive/web/kitten/current/msg06416.html Greg> and say which direction appeals to you the most. I was leaning toward option 3: use a checksum independent of option 3961. I had planned to propose that in a more detailed review. I agree option 2 would be more convenient but also agree that we'd need to make sure the prf has the required properties. I'd be happy to meet with you and see if we think that's the case if you're interested in that. Greg> I went with Greg> this approach because it reflected WG consensus at the time, Greg> and tried to be up front about it (I sent Greg> https://www.ietf.org/mail-archive/web/kitten/current/msg06427.html Greg> with a clear subject line). I understand. I think the issues I'm bringing up have not been adequately considered by the WG. I think a lot of people involved in those earlier discussions including the design of RFC 3961 are not currently involved in the WG (or the IETF). I would not generally describe myself as involved in the IETF these days. So, I think it is reasonable for the WG to consider whether this new information causes the WG to change consensus. >> Permitting non-deterministic checksums was an intentional >> decision during the development of RFC 3961. The theoretical >> basis behind deterministic checksums is dubious at best; there >> are a lot safer models for non-deterministic checksums just as >> there are better theoretical (and practical) models behind >> non-deterministic encription. Greg> We have had a deterministic checksum tightly coupled to every Greg> enctype after single-DES, and have used only those Greg> tightly-coupled checksums in standards documents for many Greg> years. It sounds like you believe that the point of permitting non-determisistic checksums was to support the existing DES checksum types. While we certainly needed to do that, there was a desire to permit things like salting a checksum or selecting a function from a family of functions if general attacks against a fully known function got stronger. Around the time of the MD5 and SHA-1 concerns, this felt like a very important potential fallback. I think it still is. Greg> We also haven't ever introduced a checksum type Greg> negotiation mechanism other than "this enctype implies this Greg> mandatory-to-implement checksum." So I don't agree with this Greg> at all; I think the value of admitting non-deterministic Greg> checksums is highly dubious, and that it's vanishingly Greg> unlikely that we would ever migrate towards non-deterministic Greg> checksums in the future. Greg> If I could go back in time, I would strongly argue for Greg> deterministic keyed checksums to be a function in the enctype Greg> profile, and for checksum types to not be a thing. If I could go back in time, I would certainly argue for checksum types to not be a thing. You seem to be conflating checksum type negotiation with deterministic checksums. I'm assuming if we wanted a checksum that was not deterministic, we'd either introduce it at the same time as an enctype migration or if we were responding to an attack, introduce a new enctype explicitly for the checksum type. I think it's fairly unlikely we're going to introduce a new enctype that sees wide use until we see some sort of attack we're responding to. I think whether we look at nondeterministic checksums will depend on the state of our confidence in our hashes at the time. Greg> Having a Greg> type registry purely for unkeyed checksums would be okay if we Greg> had a need for it. But having checksum types with different Greg> properties lumped together, in a separate registry from Greg> enctypes, is how we got CVE-2010-1324 and friends. We're in agreement that RFC 1510's handling of key types, enctypes and checksum types was a huge mess. We tried to clean that up with RFC 3961 but were unable to remove checksum types because of legacy. RFC 3961 does not come out and say that for new enctypes you have one checksum type per enctype, but that's the only sensible thing to do. >> Such a change should be in its own standards track document not >> combined with this specification. Greg> I am a little surprised to hear that. We don't have a history Greg> of being sticklers about document scope; for example, RFC 6806 Greg> introduced PA-REQ-ENC-PA-REP and FAST negotiation, despite Greg> being primarily about referrals. I don't think those changes were reversing previous consensus. I think that if the WG is going to reverse a consensus decision it has revisited multiple times before, writing a document to call that out and to get the review from people who thought about those issues is valuable. I have no concerns about lumping in non-controversial changes into other documents. From nobody Tue Jan 30 20:03:02 2018 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C031314FE; Tue, 30 Jan 2018 20:03:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: kitten@ietf.org, kitten-chairs@ietf.org, ekr@rtfm.com, kaduk@mit.edu X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151737138101.7743.1028280751943380536.idtracker@ietfa.amsl.com> Date: Tue, 30 Jan 2018 20:03:01 -0800 Archived-At: Subject: [kitten] kitten - Not having a session at IETF 101 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 04:03:01 -0000 Benjamin Kaduk, a chair of the kitten working group, indicated that the kitten working group does not plan to hold a session at IETF 101. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Tue Jan 30 20:06:29 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C73E131963 for ; Tue, 30 Jan 2018 20:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 oW0TAk-RaWFQ for ; Tue, 30 Jan 2018 20:06:26 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 CE11A131957 for ; Tue, 30 Jan 2018 20:06:22 -0800 (PST) X-AuditID: 1209190f-145ff70000006dce-df-5a7140bd57c9 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-4.mit.edu (Symantec Messaging Gateway) with SMTP id 42.EE.28110.DB0417A5; Tue, 30 Jan 2018 23:06:21 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w0V46Kdg024438 for ; Tue, 30 Jan 2018 23:06:21 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w0V46Hjp003126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 30 Jan 2018 23:06:20 -0500 Date: Tue, 30 Jan 2018 22:06:17 -0600 From: Benjamin Kaduk To: kitten@ietf.org Message-ID: <20180131040617.GD12363@kduck.kaduk.org> References: <20180109025728.GQ25484@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180109025728.GQ25484@kduck.kaduk.org> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOIsWRmVeSWpSXmKPExsUixCmqrLvXoTDK4PcMc4ujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEr42bne8aCTSwVGy4/Z2xg3MzcxcjJISFgIvHq5w4gm4tDSGAx k8TCm4egnOOMEn9nPGCFcF4zSexvvQzWwiKgKnF5zjNGEJtNQEWioRsiLiIgLLF76zswW1jA XKLr9hs2EJsXaMWM14eZQGwhIPvekV5WiLigxMmZT1hAbGYBLYkb/14C1XAA2dISy/9xgIQ5 BUwlduy7zA5iiwooS+ztO8Q+gZF/FpLuWUi6ZyF0L2BkXsUom5JbpZubmJlTnJqsW5ycmJeX WqRropebWaKXmlK6iREcepL8OxjnNHgfYhTgYFTi4eWoKIgSYk0sK67MPcQoycGkJMq7OhUo xJeUn1KZkVicEV9UmpNafIhRgoNZSYSXRacwSog3JbGyKrUoHyYlzcGiJM7rbqIdJSSQnliS mp2aWpBaBJOV4eBQkuCNsAdqFCxKTU+tSMvMKUFIM3FwggznARq+3g5keHFBYm5xZjpE/hSj MUfbyidtzBw3XrxuYxZiycvPS5US53UGGScAUppRmgc3DZQ+JLL317xiFAd6TpiXBaSKB5h6 4Oa9AlrFBLRqRW4uyKqSRISUVAPjrkm+pk5x+nf/fcg6+2TaqScRC6/wLLm6PcJ67hvV9mKL +jKD/by2s55q975i6N4ieDRxnsuxqRIl09tnvmzyDEx9YJjqvuv8r8sHP2U9+KK+dsLBqK6X U4yvzV1n+DF/5kbxr2L5CowXipoc5K4dKDjcPEnyu8Gh0/psZb/jb7ZWpoWeXz4jUYmlOCPR UIu5qDgRAJA8FuT6AgAA Archived-At: Subject: Re: [kitten] Any topics for IETF 101 (London)? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 04:06:27 -0000 On Mon, Jan 08, 2018 at 08:57:29PM -0600, Benjamin Kaduk wrote: > Hi all, > > Session request submission is open for IETF 101 in London (March > 17-23). Please let the chairs know if you will be attending and > have topics you would like to discuss; if there is insufficient > interest, we will not request a session. As you saw, we didn't really achieve critical mass. Of course, I will be in London and will be happy to talk to folks, though you may need to send me a heads-up to make sure that I'll have some time set aside to do so. -Ben From nobody Wed Jan 31 13:43:12 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F2812FAAD for ; Wed, 31 Jan 2018 13:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 JvcjKJtJquim for ; Wed, 31 Jan 2018 13:43:09 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 1EA7C12FAAE for ; Wed, 31 Jan 2018 13:43:08 -0800 (PST) X-AuditID: 12074422-2b3ff70000002aa5-a5-5a723869fc40 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-5.mit.edu (Symantec Messaging Gateway) with SMTP id 73.BA.10917.A68327A5; Wed, 31 Jan 2018 16:43:07 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w0VLewLV032400; Wed, 31 Jan 2018 16:41:00 -0500 Received: from [18.101.8.247] (VPN-18-101-8-247.MIT.EDU [18.101.8.247]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w0VLeuqu007096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 31 Jan 2018 16:40:57 -0500 To: Sam Hartman Cc: kitten@ietf.org References: <5777908c-6752-e623-d25d-3b5b23bcbda4@mit.edu> From: Greg Hudson Message-ID: <7d4423be-7737-b97f-ba6c-92e4552804f3@mit.edu> Date: Wed, 31 Jan 2018 16:40:56 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsUixG6nopttURRlMP0pj8XXtgdsFkc3r2Jx YPJYsuQnk8fKqafZA5iiuGxSUnMyy1KL9O0SuDI67jYwF6xUqFi0/SdzA+NkqS5GTg4JAROJ Y7efMXcxcnEICSxmkjhy8xELhLORUeLjlxYmCOcok8SHrztZQVqEBbwl7n+8ywRiiwioS6y+ NIkdxGYWEJZYvuYsG0RDA6PE5rXv2UASbALKEuv3bwUay8HBK2Al8eChH0iYRUBV4vTZ7WAl ogIREk0z54LN5xUQlDg58wkLiM0poCtxrLmJCWK+usSfeZeYIWxxiVtP5kPF5SW2v53DPIFR cBaS9llIWmYhaZmFpGUBI8sqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXVO93MwSvdSU0k2M4NB2 UdrBOPGf1yFGAQ5GJR7eCRcKo4RYE8uKK3MPMUpyMCmJ8t66AxTiS8pPqcxILM6ILyrNSS0+ xCjBwawkwrtRpChKiDclsbIqtSgfJiXNwaIkzuthoh0lJJCeWJKanZpakFoEk5Xh4FCS4N1o DtQoWJSanlqRlplTgpBm4uAEGc4DNPybGcjw4oLE3OLMdIj8KUZdjhsvXrcxC7Hk5eelSonz toIMEgApyijNg5sDTkmpHN9fMYoDvSXMexekigeYzuAmvQJawgS05Gd2IciSkkSElFQDo8Xm aYr6v/+8e7+03vCHQHKHY6z9iShNzRVXS9fruYhkxPb4JKwL2KLrwHE/+pTwtI1eji/kim/0 qX/MUWv9ptt7LuLvvhPpLs+KvtfEnPjLs6so1avo9TW18CjRNenyyxxnb/8nd5tDfyqjjrvh iw1b/BR2cs3Z9clL9vrOKIa46pCXXGY+SizFGYmGWsxFxYkAlSc2ZiQDAAA= Archived-At: Subject: Re: [kitten] Concerns about draft-ietf-kitten-krb-spake-preauth-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 21:43:11 -0000 On 01/29/2018 08:14 AM, Sam Hartman wrote:> I agree option 2 would be more convenient but also agree that we'd need > to make sure the prf has the required properties. > I'd be happy to meet with you and see if we think that's the case if > you're interested in that. After a phone discussion with Sam: * PRF might not have the required properties, although it would probably still be difficult to attack. SPAKE2's security proof relies on a random oracle (implemented using a hash) over the concatenation of the party identities, the public keys, the initial secret, and the shared group element. A PRF is supposed to emulate a random oracle if the function is chosen randomly from the PRF family, but in this case we're choosing it based on a low-entropy secret. It seems unlikely that an attacker could make any headway since a large part of the PRF input string (the shared group element) is unknown, but the security proof most likely does not work. * If we want to hew closely to the SPAKE2 security proof, we probably need to bring an unkeyed hash into the operation (as the current draft already uses PRF+ instead of a hash function for the final key derivation). There are two possibilities for choosing the unkeyed hash, the second of which I hadn't considered in detail: 1. Choose the hash based on the group number (make it part of the group definition). There are two concerns here: 1a. If the KDC issues an optimistic challenge and the client rejects it (going back to issuing a SPAKESupport), the hash function might change. We could fix this by not including rejected optimistic challenges in the transcript, which should be fine; the subsequent group negotiation should still be secure. 1b. There's no hard guarantee that the group's hash function output size is as large as the enctype's random-to-key input size, although SHA-256's output size would likely be good enough for the forseeable future. So we would have to specify an exception case when the hash output size isn't big enough, or use a hash extension scheme, which is easy to do (it would look a lot like PRF+) but is fiddly. 2. Choose the hash based on the enctype, essentially defining a SPAKE-specific extension to RFC 3961 in the form of a mapping from enctype number to hash function. Mapping this way means we can ensure that the chosen hash function output size is at least as large as the enctype random-to-key input size, for each enctype. We would probably want to use SHA-256 for every existing enctype, even for enctypes which use SHA-1 or something worse internally. One question which informs the choice between (1) and (2) is whether bigger, harder groups (P-521 as compared to P-256, for example) benefit from larger intermediate hashes. I don't think they do, as everything gets hashed down to the enctype random-to-key input size in the end. * Using recursive hash operations to limit how much the KDC has to remember should be fine, under the random oracle assumption. random-oracle(random-oracle(A|B)|C) should look the same to an attacker as random-oracle(A|B|C), assuming the intermediate hash size is too large to practically attack. > You seem to be conflating checksum type negotiation with deterministic > checksums. I'm assuming if we wanted a checksum that was not > deterministic, we'd either introduce it at the same time as an enctype > migration or if we were responding to an attack, introduce a new enctype > explicitly for the checksum type. So the concern here (clarified via the call) is that we could find a theoretical attack on existing uses of checksums, which could be resolved using non-deterministic MACs, and perhaps isn't bad enough to create an immediate practical attack but is bad enough that we want to migrate away from deterministic MACs via new enctypes. I continue to think this scenario too unlikely to worry about, but Sam having raised the objection does motivate me to more strongly consider substituting an unkeyed hash for the draft's existing key derivation and transcript checksum methods. From nobody Wed Jan 31 14:11:01 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2E012FB05 for ; Wed, 31 Jan 2018 14:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.931 X-Spam-Level: X-Spam-Status: No, score=-6.931 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 LEKm1jwPxGwk for ; Wed, 31 Jan 2018 14:10:58 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 076CB12FAEA for ; Wed, 31 Jan 2018 14:10:56 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AA1B068E23; Wed, 31 Jan 2018 22:10:55 +0000 (UTC) Received: from ovpn-117-243.phx2.redhat.com (ovpn-117-243.phx2.redhat.com [10.3.117.243]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3F72A5C20C; Wed, 31 Jan 2018 22:10:55 +0000 (UTC) Message-ID: <1517436654.13097.119.camel@redhat.com> From: Simo Sorce To: Greg Hudson , Sam Hartman Cc: kitten@ietf.org Date: Wed, 31 Jan 2018 17:10:54 -0500 In-Reply-To: <7d4423be-7737-b97f-ba6c-92e4552804f3@mit.edu> References: <5777908c-6752-e623-d25d-3b5b23bcbda4@mit.edu> <7d4423be-7737-b97f-ba6c-92e4552804f3@mit.edu> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Wed, 31 Jan 2018 22:10:55 +0000 (UTC) Archived-At: Subject: Re: [kitten] Concerns about draft-ietf-kitten-krb-spake-preauth-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 22:11:01 -0000 On Wed, 2018-01-31 at 16:40 -0500, Greg Hudson wrote: > On 01/29/2018 08:14 AM, Sam Hartman wrote:> I agree option 2 would be > more convenient but also agree that we'd need > > to make sure the prf has the required properties. > > I'd be happy to meet with you and see if we think that's the case if > > you're interested in that. > > After a phone discussion with Sam: > > * PRF might not have the required properties, although it would probably > still be difficult to attack. SPAKE2's security proof relies on a > random oracle (implemented using a hash) over the concatenation of the > party identities, the public keys, the initial secret, and the shared > group element. A PRF is supposed to emulate a random oracle if the > function is chosen randomly from the PRF family, but in this case we're > choosing it based on a low-entropy secret. It seems unlikely that an > attacker could make any headway since a large part of the PRF input > string (the shared group element) is unknown, but the security proof > most likely does not work. > > * If we want to hew closely to the SPAKE2 security proof, we probably > need to bring an unkeyed hash into the operation (as the current draft > already uses PRF+ instead of a hash function for the final key > derivation). There are two possibilities for choosing the unkeyed hash, > the second of which I hadn't considered in detail: > > 1. Choose the hash based on the group number (make it part of the > group definition). There are two concerns here: > 1a. If the KDC issues an optimistic challenge and the client rejects > it (going back to issuing a SPAKESupport), the hash function might > change. We could fix this by not including rejected optimistic > challenges in the transcript, which should be fine; the subsequent group > negotiation should still be secure. > 1b. There's no hard guarantee that the group's hash function output > size is as large as the enctype's random-to-key input size, although > SHA-256's output size would likely be good enough for the forseeable > future. So we would have to specify an exception case when the hash > output size isn't big enough, or use a hash extension scheme, which is > easy to do (it would look a lot like PRF+) but is fiddly. > > 2. Choose the hash based on the enctype, essentially defining a > SPAKE-specific extension to RFC 3961 in the form of a mapping from > enctype number to hash function. Mapping this way means we can ensure > that the chosen hash function output size is at least as large as the > enctype random-to-key input size, for each enctype. We would probably > want to use SHA-256 for every existing enctype, even for enctypes which > use SHA-1 or something worse internally. The one concern here is, what happen if the hash function turns out to be broken down the line ? How would new and old code negotiate what hash to use ? Or is the thinking that we'd add new enctypes if the hash function is broken anyway so new enctypes will be mapped to this new hash function ? What happens when a new enctype is introduced ? Will there have to be also an explicit allocation of a hash type to be use for SPAKE? Will it be implicit ? At least SHA-256 or whatever the enctype uses if "better" ? > One question which informs the choice between (1) and (2) is whether > bigger, harder groups (P-521 as compared to P-256, for example) benefit > from larger intermediate hashes. I don't think they do, as everything > gets hashed down to the enctype random-to-key input size in the end. > > * Using recursive hash operations to limit how much the KDC has to > remember should be fine, under the random oracle assumption. > random-oracle(random-oracle(A|B)|C) should look the same to an attacker > as random-oracle(A|B|C), assuming the intermediate hash size is too > large to practically attack. > > > You seem to be conflating checksum type negotiation with deterministic > > checksums. I'm assuming if we wanted a checksum that was not > > deterministic, we'd either introduce it at the same time as an enctype > > migration or if we were responding to an attack, introduce a new enctype > > explicitly for the checksum type. > > So the concern here (clarified via the call) is that we could find a > theoretical attack on existing uses of checksums, which could be > resolved using non-deterministic MACs, and perhaps isn't bad enough to > create an immediate practical attack but is bad enough that we want to > migrate away from deterministic MACs via new enctypes. I continue to > think this scenario too unlikely to worry about, but Sam having raised > the objection does motivate me to more strongly consider substituting an > unkeyed hash for the draft's existing key derivation and transcript > checksum methods. I do not have an issue with this, assuming we do not corner ourselves with the choice of hash. Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc From nobody Wed Jan 31 14:56:27 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFB412FB66 for ; Wed, 31 Jan 2018 14:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 LR-Ar1pHSz59 for ; Wed, 31 Jan 2018 14:56:23 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 8F3C012FB4D for ; Wed, 31 Jan 2018 14:56:12 -0800 (PST) X-AuditID: 12074425-01dff70000003469-db-5a72498932c6 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id E4.D0.13417.A89427A5; Wed, 31 Jan 2018 17:56:10 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w0VMu49L012059; Wed, 31 Jan 2018 17:56:05 -0500 Received: from [18.101.8.247] (VPN-18-101-8-247.MIT.EDU [18.101.8.247]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w0VMu1wL031876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 31 Jan 2018 17:56:03 -0500 To: Simo Sorce , Sam Hartman Cc: kitten@ietf.org References: <5777908c-6752-e623-d25d-3b5b23bcbda4@mit.edu> <7d4423be-7737-b97f-ba6c-92e4552804f3@mit.edu> <1517436654.13097.119.camel@redhat.com> From: Greg Hudson Message-ID: Date: Wed, 31 Jan 2018 17:56:01 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1517436654.13097.119.camel@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsUixG6notvlWRRlcOOpkcXXtgdsFkc3r2Kx +DF3EasDs8eSJT+ZPN7vu8rmsXLqafYA5igum5TUnMyy1CJ9uwSujHP/5jEVzOCrmPP1CVsD 42LuLkZODgkBE4lbp/6wgNhCAouZJK5NVeli5AKyNzJKPOs4xgjhHGWSeD/xCStIlbCAt8T9 j3eZQGwRAVeJpauvM4PYzALCEsvXnGWDaLjNKNH3fB1Ygk1AWWL9/q1gK3gFrCRenLnJBmKz CKhKvFl5jR3EFhWIkGiaOZcVokZQ4uTMJ2D1nEDnHV17kg1igbrEn3mXoJaJS9x6Mp8JwpaX 2P52DvMERsFZSNpnIWmZhaRlFpKWBYwsqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3Qt9HIzS/RS U0o3MYLD3UV1B+Ocv16HGAU4GJV4eCdcKIwSYk0sK67MPcQoycGkJMp76w5QiC8pP6UyI7E4 I76oNCe1+BCjBAezkgjvRpGiKCHelMTKqtSifJiUNAeLkjivh4l2lJBAemJJanZqakFqEUxW hoNDSYL3vQdQo2BRanpqRVpmTglCmomDE2Q4D9BwHk+Q4cUFibnFmekQ+VOMuhw3XrxuYxZi ycvPS5US57UEGSQAUpRRmgc3B5ymUjm+v2IUB3pLmFcUZBQPMMXBTXoFtIQJaMnP7EKQJSWJ CCmpBka3QCn73oCVJzt9lX5YJqR+EBBV4C6696aNfdHPBZOCN124+zBZVJGb//yJUyqtVTU7 iv9lfD1pub4yLWST9GRHi7lfZBRfZU/5HlnR7lj831guy+32hDubxXcpcay7qhU6v9rv54Kk nG/msZ4nmjdv9IyVEF34pvqUU93aeRkSaUq5s6pq1iuxFGckGmoxFxUnAgCOgHpPLgMAAA== Archived-At: Subject: Re: [kitten] Concerns about draft-ietf-kitten-krb-spake-preauth-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 22:56:26 -0000 On 01/31/2018 05:10 PM, Simo Sorce wrote:>> 2. Choose the hash based on the enctype [...] > The one concern here is, what happen if the hash function turns out to > be broken down the line ? > How would new and old code negotiate what hash to use ? > > Or is the thinking that we'd add new enctypes if the hash function is > broken anyway so new enctypes will be mapped to this new hash function > ? We would have to migrate to a new enctype to change the hash function we use in SPAKE. That's a high cost in some scenarios--like if someone discovers a horrible preimage attack on SHA-256, but SHA-1 still appears as preimage-resistant as it does today, so that aes-sha1 still seems like a decent enctype to use for every purpose other than SPAKE. But I think those scenarios are vanishingly unlikely. > What happens when a new enctype is introduced ? Will there have to be > also an explicit allocation of a hash type to be use for SPAKE? > Will it be implicit ? At least SHA-256 or whatever the enctype uses if > "better" ? When a new enctype is defined, we would also have to populate its entry in the SPAKE mapping of enctype to hash function (which could be an IANA registry). If there's no mapping for an enctype then that enctype can't be used with SPAKE. But it should be easy to update the SPAKE enctype-to-hash registry in the same document as we define a new enctype. There is the option of specifying "SHA-256 as long as the key size is <= 256 bits unless there's an explicit mapping," but that option runs a serious interoperability risk--one party might use the SHA-256 default (through negligence or some time window between the enctype assignment and the SPAKE mapping update) while the other party uses a different, explicitly specified hash function.