From nobody Wed Jan 23 13:16:28 2019 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 EC3C8130F04; Wed, 23 Jan 2019 13:16:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robbie Harwood To: X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Cc: kitten@ietf.org, nico@cryptonector.com, kitten-chairs@ietf.org, iesg-secretary@ietf.org, Nicolas Williams Message-ID: <154827818593.7505.14076287003039165181.idtracker@ietfa.amsl.com> Date: Wed, 23 Jan 2019 13:16:25 -0800 Archived-At: Subject: [kitten] Publication has been requested for draft-ietf-kitten-krb-spake-preauth-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 21:16:26 -0000 Robbie Harwood has requested publication of draft-ietf-kitten-krb-spake-preauth-06 as Proposed Standard on behalf of the KITTEN working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-kitten-krb-spake-preauth/ From nobody Tue Jan 29 14:21:47 2019 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 768BC130EDB; Tue, 29 Jan 2019 14:21:45 -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, kaduk@mit.edu, rharwood@redhat.com X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154880050543.7839.12903931299960132468.idtracker@ietfa.amsl.com> Date: Tue, 29 Jan 2019 14:21:45 -0800 Archived-At: Subject: [kitten] kitten - Not having a session at IETF 104 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 22:21:46 -0000 Robbie Harwood, a chair of the kitten working group, indicated that the kitten working group does not plan to hold a session at IETF 104. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Wed Jan 30 14:48:16 2019 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 D6F6E130EBD; Wed, 30 Jan 2019 14:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=mit.edu 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 GgfdrxYavJ8D; Wed, 30 Jan 2019 14:48:12 -0800 (PST) Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730104.outbound.protection.outlook.com [40.107.73.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4767130E25; Wed, 30 Jan 2019 14:48:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JpGgH2txGTrGmEZQ9mY4N0J14gj9+UL3QWvDj/69xIk=; b=n+9pWVNCvliZvodk72TcEy8O9ZUl5CGpgmK9/bx+QRkbSkNiGNF5VD5FpNjca5REMrzbyW+9eOmCEUo9+5VtyzxOB3dXLeKA1uRsFAXuh0WafqGy/AQlakgIORxXnT1wA5RV0gNGLGvOW8aUbb9FqbWTr5r7xzXRJ5PWY56bGfU= Received: from MWHPR01CA0036.prod.exchangelabs.com (2603:10b6:300:101::22) by SN6PR01MB3854.prod.exchangelabs.com (2603:10b6:805:19::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.19; Wed, 30 Jan 2019 22:48:10 +0000 Received: from BY2NAM03FT011.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::204) by MWHPR01CA0036.outlook.office365.com (2603:10b6:300:101::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.17 via Frontend Transport; Wed, 30 Jan 2019 22:48:09 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by BY2NAM03FT011.mail.protection.outlook.com (10.152.84.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.10 via Frontend Transport; Wed, 30 Jan 2019 22:48:09 +0000 Received: from kduck.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.14.7/8.12.4) with ESMTP id x0UMm6ZX017678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Jan 2019 17:48:08 -0500 Date: Wed, 30 Jan 2019 16:48:06 -0600 From: Benjamin Kaduk To: CC: Message-ID: <20190130224805.GF49072@kduck.mit.edu> References: <20190130224555.GE49072@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20190130224555.GE49072@kduck.mit.edu> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(346002)(136003)(39860400002)(376002)(2980300002)(189003)(199004)(53754006)(2906002)(786003)(46406003)(450100002)(50466002)(426003)(4326008)(97756001)(446003)(476003)(11346002)(956004)(36906005)(58126008)(126002)(16586007)(356004)(106002)(88552002)(316002)(246002)(8936002)(14444005)(8676002)(305945005)(478600001)(26826003)(6916009)(1076003)(47776003)(33656002)(86362001)(76176011)(106466001)(26005)(7696005)(53416004)(23726003)(75432002)(486006)(336012)(55016002)(229853002)(6246003)(2351001)(186003)(104016004)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR01MB3854; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM03FT011; 1:2D1rMLNceVprBQN8ZnlK7MUY6ZE+Eggyh0id2R2aRr0XUkNUHC+xXwYp8ARddjheKNlO4ZmqCcvlAfUXKCJXTHdECXwceS6i8J8GNJB3gHzumQO2Ojxg/ewSrXmxRbAdS+/Shxkc7W1r6GOGrsM2MUBPaz3wn6slldaTQdyXnWQ= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e0081be0-e72d-431e-f473-08d687050209 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060); SRVR:SN6PR01MB3854; X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB3854; 3:Or81SODWXVLtBlRT6kFLKBpwZhf2X3nzoe8v/U6xNMsmMW9xliYq1kJz9bxhcq/xVYgqYwfIGRoW0f42cYpwrlLSc+sjV6OB4und0o8x7IR0PTRKisGZlDhlzvm5u9lJtepHnMULOvQhwtY9yUPtKliR29NiQHyPa5tW7xzaiBbKpMuMGRQTSv0X1gcmzvHhWj4cOUGCFJi/fStD2GTlvR1eGQxdH4aREmzZL9kQdsjRd8i6w+I65mosFDTKG0Dau1YgtTN4KEkcT3p/Q1y/3NWrffHwlXPXaBbM/nj0ewvmromgQNkX2QD9ebU8msbSTQU0/SeDYr/HWDXFBEmOY89AIV3MtY6zNclCcMwzhIvlB1svOnXVt1aIszFLpfOj; 25:oI5sULXQYYi+8FQWeuIhOCUf26UbS8xCRFWMmjbQOfbNV0+gCgLkflMiE6r1Fkm4DHXrV1FoTX9WlTMhcWdJdo8VZRCyUz1dP8jordAKpJ5/3RFPfY8Or9FSYlsHGSC3EupEURq9Cn8d1v/WahYojVvqPu0jX72pI29Zz1oVWWbRuMDeBsxjBgnZYW7ImCwAjX3K2T+zUsOIm/izNiCgaBHgF03eQYQ7YtAUWiBT25uvz9us0hN6S8GlWV8Kj9+GGlvH19koRbHoUssLrJN9hgfFYx6nJJKDMx+xD4AJWgkK3YkltRBTiNSVYDH2hUucjc28J9HV1arPjGmttP6Bwg== X-MS-TrafficTypeDiagnostic: SN6PR01MB3854: X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB3854; 31:e5rAiVAJHvQRocCX84u+3u/FfM7XEHNwSCN+ZDoe/6RrJYfuK5G46BRTcU9syYPqGC1thAgFPMbggls7UVPSg9t1DIgiEXcOLiNgHlMy3C5r+Zjtn9/y5S2XWqkEBoTkOq3VMp69C0vx57+fHRiLzIn4EsJ8pd6BxG2E+rZr6ZROVGqmybNxNiAIA7T6xC8MhkJIG/j5UASvDEkSGgw8qoIY+hjEQarTeg1Einvlveo=; 20:amSxvhTcd8JeSzSc39eN0wvMzlH5jBT5X96YV7Ls/1mW+mYZ3zJSKU7iZ2ABGtuIor5TH1STEoh1lhIVjtqD2pVVx2bWUEf4J6fI/r3ziBV6cpLQWbYxrEDdZLq/fuQwutxwJRrhry723ymdanPUmxC858XWFSR7rvBKUFMmY/a1GWR33p3v2uYHlXhyyRZ2Zr6MMICx3V9QvS35J3nH/MqKDtEkOCwArkOuxxrAL0HA4+ASHZufcmqk8nF43ur+zhgLqywyOnqMvBmZAF4FZwcpO+bSO+h533cLJq2rPxq79pf78MkzIoaA+jNk5J8Y977iXiCnAYh/92Blj/bpcb0QAUE/+c65fwosv//NC54LhVNCJxQG1aBHmnVmndM9GDSVusQFcb3KtwCZqGpT6A+6UGlKGI7xdTwDVnfFvyL+2p0rEip0fVi0DTkrJxexwhWWy0KYVGTVY3gK2bKQGtQUyYwLPEdfOm8ltG5Xds9t7KJuP48+dMkEey5fYVSEGGLsgdT5+cSDj0uEwJwWCsAlc+q/pmRFe+v6KmemENZSGAGZYksXzZC+ulIeRMmvDZbBT5HqCIIv9EIzCm27ZLxPfrYKEyV2x8WqOq6GFzQ= X-Microsoft-Antispam-PRVS: X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB3854; 4:n5ZPOTJl2A3uItajEkDP0WXWeDUdWMmmot41Lfqq6FCUUwgjQIfS//vofe/l1AbfpnVAxaIGhezvpdukz31zlQi75gxvLXUDZrI2BO72f/77tCoYlremz+QwirtsN2bl2CdC6KeSAYLmTHakTQ/RRvsy49rfwRyxX0FDel79OlYc/Qqrc9SFNadkF38qQZxbYccpZjEw26hDh1tOU1MQXAFny/ztDwLu2v+RiRk8Nfcdogqfa+mFTo9jRRaQHf2qN0bdrkTxIEs/hGbt3j1q+CA5rQ0P6CqHU8OepuWHT63fpVhLAQBH/IUKJbOQH2U+ X-Forefront-PRVS: 0933E9FD8D X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN6PR01MB3854; 23:EFTPXVZ8Ni8eQfyWDYxZmIiOe9dwD0oFJVLD2QJbO?= =?us-ascii?Q?q86XSG3ACRdgELXUNz+SRDGDr5eH277y/IEGdo1Mnye/HlgRikfZU263+dKX?= =?us-ascii?Q?wg2lSwpkiiGjkowVnof0E8WzffMJSap+VrNWRuMySMoaiDyzeMPup2sQtEVD?= =?us-ascii?Q?gvYIxzlZTY0L3qib/0+V+2yqrie7IzUkpfjGwS6e+RkchXnqmlF6urSevXYF?= =?us-ascii?Q?kfnrFe6clEWg/hkCT8yLDHrzIWMsk+7CV6iy6b6oEJvuIEOhWnzyCULdaTa8?= =?us-ascii?Q?+i0KrV8zovrgaSWlkgKXer+QwrDbbivYzhzY5RPgTM3ll27js6pZKBekQpA8?= =?us-ascii?Q?gBPeKndexHKf4qz2Mgsdd58ja9KTslMOTLM79GPxSFyHXbphYBSFo6JXcOVd?= =?us-ascii?Q?+RxxyCI1nGHFRtQhub9lsef/IJNO5PDnk6lAbQ+OhnajWf+dDDHpot7UC1Gh?= =?us-ascii?Q?usYUzdD922f5enHqWDFFQOp/qYwEJ1VFGLpXUiiN6tTn18wxG0fZoaS5nu0a?= =?us-ascii?Q?CSt3ZJWLSgA6YYi2H2+fJSLoAyoV83RFII/w5U3oja9AFDeFXQUmriRSByE8?= =?us-ascii?Q?iLNHGXW457+SyHsci2bEFFQjnD89LObKvRuy0QLebqjLuIo1pmRaIcu8KLiR?= =?us-ascii?Q?f2q1K4tK2eUPXWOyrg7KzCAz8Sbzq80Aj9pHh/jZHycAh5fbeHSDEaG7f7XA?= =?us-ascii?Q?MS/zP2XBcXV6Ur5aNX5GBD5/2OrXcdbas4EVRBMH+MkGqdz/1M6svuu+3hfG?= =?us-ascii?Q?Jj3HK5On8FwZ0J0TUDB6g4OjRsyR4C4iumzcnCLwznzv21ISUozNaKkEk+Ua?= =?us-ascii?Q?IfwkGwjlJbSgSOntkN7qIkKOHVFWb8rn+u6LZPDUnDL1WIdNEHTxGwJaB9qU?= =?us-ascii?Q?0KXHDE2s3O2hYOo7iMb1VJWz2RrNB2o3yBxrP6tlBLVtQAKNkbTwGOjieYJq?= =?us-ascii?Q?tgQfmD1aol3TtktXhClTStHLQSuDsKY7vmBmCiTMBjlyMiG+7trmTv6wPXWv?= =?us-ascii?Q?Z7/iHys+6wipiSoFsZUfm9Rh9dcMYHOHedbMijOsSi3yyRhQmnDnQygPcPfC?= =?us-ascii?Q?sw8MoIiNpqmasVb1SWL7OAjRpg9BAoukhFZe85m7/iZ+1N70PXiCUAVgEz4a?= =?us-ascii?Q?TPf83LueN/QZzs03JvPWP06FVQSgfa+aR/BT+LTD5YiajPROIbaqxyMBfZAh?= =?us-ascii?Q?tfknS0gfwygEGEnOETvsiIYtzsVkvN6UKi1q9SoYl9R0lHH1OogSlvWIKNJd?= =?us-ascii?Q?/ierhEbMvIfFcVpuok=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: z67V7d1nMyY0RpS7YZM+NQXkdJ/RA6pZHQkwATIRR8PoTYCB14+VX6qPaGci+crZr90fooOXAyjmwZMa83jw9PFwAkTdOvuvcuWMMFtEMQBruvkYYtUI2+nMqJVspbP84OvZMPCqWVX7d/MOlEWyHkyWkZaynv41+ncJNQ4LKxIK/m4i2PBbHlmBo4ijHplFAf8iebAsTu0uCf/e5ULS5BYd0S625epp4T83srRop8f19H0j4S7SSRoVJXCck33TcmpETmwcwWmSfGR4l1Uel0RL6Sqqc1vkBam/99gtPiGi7bJlhM0ufe9LmrDLN3oj6CXQ/bJDjG3VM86dqjuhLv9b8nWSv3ZLGLZUlvifRiJZ1qci8o9o2IodgJmeiQq4BLZSnlOgQsxV4liQJqFwG1whMH7jIPAU8M7Hn4aYbMQ= X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB3854; 6:fgwvBkVq8+bfgnpC1v9Fu7bkHIG9i+9kzZ+NH5Qe+kLeDUOUKgrtF6bFBb24S6Qjd4dAxTx9Jtenq6V13CTsB6FwikPRDnBwiCkgdFkjrrTg5QcEyh9mg/ZSOxkzfDg2HZ9xMUzxmbuxByCaihVJEeefuiLBpQz1ml7BxxML+iNluqqPhYNagSQfDuxr5nn7fCN79vfY0vNc32adBAJH/O//th9qMJLRv1jvZcTEBXvulZ1vdTYsuND8LgFDjs4DAU3byt0VnZu0GIR6oeUXbor5e0nHBBWPUvojQd6i0tRGcmYKwYGKwJDsr30YtFSlKzU50ECPBofcOMBm+n28IeGzxRlzLHLqjvpjorvn1bFC7Sh2bg184BO51ywZ5UpxSz63n5ScBf15j4yHtEUqC/qdGJfzvXQX2THgmtHghCI05eDgGye9rERvctMMdoe9MlIcUnbh+JhTj37NBKr0aQ==; 5:ZvvjSh0BIhjtABwhu3pNOA7Tcg+R1cIhLp8ALaxVRB5Gi3FCluaVHFPd01v4xnN5XSM1qU2nCvK0Nq091uDC4ZiBt3glz/DtiVGm5Hsvg7Smw3t2xlLbm0IVdwp9xkkdkv+6RbKMvYgu91MbXixNAsoBHlEJqxFRH4W2dUs8gw7Z33NbZg/aQgNsOw8/oszdpSk3GwBVrbHVLNC4hkNbog==; 7:tAox4WvAQqfn2fTx3yGhweAsNFK+Rf8+WOZlqcQuUDecYsRzgPT8drFqXBv2kgLihH7doiyDz2VhzDh9foV/sboEwnGkA4dnbGnEUdZvSOl/mJusTNTt/xVhn7/lueEylN4p5JFJ4NCnnDIWfZdMrA== X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2019 22:48:09.5264 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e0081be0-e72d-431e-f473-08d687050209 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR01MB3854 Archived-At: Subject: Re: [kitten] AD review of draft-ietf-kitten-pkinit-alg-agility-03 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 22:48:15 -0000 [adding the WG list, sigh] On Wed, Jan 30, 2019 at 04:45:55PM -0600, Benjamin Kaduk wrote: > Hi all, > > I just have a number of editorial comments that we should probably tighten > up before we send this out for IETF-wide review. Sorry for taking so long > to get to this :( > > The term "HKDF" has been claimed by RFC 5869 for HMAC-based > Extract-and-Expand, which is not what we're doing here; we should avoid > using that acronym, perhaps in favor of "hash-based KDF". > > In the Abstract and Introduction, it looks like we need an "and" in the > list of "PKINIT key derivation function is made negotiable, and the digest > algorithms for signing the pre-authentication data and the client's X.509 > certificate", since the latter two items are both sub-items of "signing", > thus there are only two items in the top-level listing. > > It's probably worth a(n informative) reference to BCP 201 when we say that > the IETF "called for actions to update xisting protocols to provide crypto > algorithm agility" in the Introduction. > > Basically every "official" reviewer is going to note that BCP 14 now > includes RFC 8174 as well as RFC 2119, with updated boilerplate text. > Let's save them the time of having to note it :) > > Section 3 > > and the corresponding Kerberos request body. This also prevents the > KDC body from being tampered with. SHA-1 is the only allowed > > Is this "KDC_REQ body"? > > When the reply key delivery mechanism is based on public key > encryption as described in Section 3.2.3. of [RFC4556], the > > I can't decide if 3.2.3 or 3.2.3.2 is a better reference for this. > > However, if the reply key delivery mechanism is based on > the Diffie-Hellman key agreement as described in Section 3.2.3.1 of > [RFC4556], the security provided by using SHA-1 in the paChecksum is > weak. [...] > > It might be worth noting more explictly that "there is nothing else to > cryptographically bind the AS_REQ to the ticket response", to emphasize the > difference to the public-key-encryption method that already digests the > entire AS_REQ into the authenticated content, using a (strong) negotiated > algorithm. > > Section 4 > > TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF > AlgorithmIdentifier > -- Contains the list of CMS algorithm [RFC5652] > -- identifiers that identify the digest algorithms > -- acceptable by the KDC for signing CMS data in > -- the order of decreasing preference. > > nit: "identifiers that identify" is a somewhat unfortunate construction; > perhaps we could go with "identifiers that indicate" instead. > > Section 5 > > When the client's X.509 certificate is rejected and the > KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned as > described in section 3.2.2 of [RFC4556], conforming implementations > can OPTIONALLY send a list of digest algorithms acceptable by the KDC > > We should probably use "implementations that conform to this specification" > to match Section 4. (Though we may get some complaints about using > "conforming" at all, too.) > > Setion 6 > > New KDFs defined in this document based on [SP80056A] can be used in > conjunction with any hash functions. > > There's some disagreement here between "KDFs defined in this document" and > "any hash functions" -- either we treat a KDF as tied to a specific hash > (which is how we allocate OIDs) or it is a generic construct that can be > instantiated for any given hash (in which case there is only one KDF not > multiple). We also want to be consistent with how we treat KDFs as > identified by OIDs in the following text, so I think something more like > "The KDF algorithm described in this document (based on [SP80056A]) can be > implemented using any cryptographic hash function" and "A new KDF for > PKINIT usage is identified by an object identifier" in the next paragraph. > > Where id-pkinit is defined in [RFC4556]. The id-pkinit-kdf-ah-sha1 > KDF is the ASN.1 structured hash based KDF (HKDF) [SP80056A] that > uses SHA-1 [RFC6234] as the hash function. Similarly id-pkinit-kdf- > ah-sha256 and id-pkinit-kdf-ah-sha512 are the ASN.1 structured HKDF > using SHA-256 [RFC6234] and SHA-512 [RFC6234] respectively. > > We seem to have not added SHA-384 to this paragraph when we added it > elsewhere. > > To name the input parameters, an abbreviated version of the ASN.1 > version of the KDF from [SP80056A] is described below, use [SP80056A] > for the full reference. > > [SP80056A] seems to call this a "KDM" and not a "KDF"; we probably want to > call out the terminology mismatch and perhaps also the section number > (5.8?). Also, the actual algorithm seems to be coming from Section 4 of > SP800-56C, not SP800-56A, if we want to be accurate about our reference. > > On the other hand, we could also save ourselves from worrying about the > precise references as much if we avoided describing ours as "an > abbreviated version of" and just say something like "inspired by" or > "similar to", which allows us to treat our formulation as the single > authoritative specification for what to do, without leaving the reader > needing to check back and see if there are any missing details. (This > would probably allow [SP80056A] (or C) to be only an informative reference, > too.) > > 4. Set key_material = Hash1 || Hash2 || ... so that length of key is > K bits. > > I think we need to say something about "truncating as needed". > > o The maximum hash input length is 2^64 in bits. > > I'm confused where this parameter comes from. On the one hand, that's an > absurdly huge value; on the other hand, why do we need to give a limit at > all? > > I think we need to say specifically that we use the DER encoding of > OtherInfo as input to the KDF. > > PkinitSuppPubInfo ::= SEQUENCE { > enctype [0] Int32, > -- The enctype of the AS reply key > as-REQ [1] OCTET STRING, > -- This contains the AS-REQ in the request. > pk-as-rep [2] OCTET STRING, > -- Contains the DER encoding of the type > -- PA-PK-AS-REP [RFC4556] in the KDC reply. > ... > } > > A couple nits in here -- is the AS-REQ "in" the request or perhaps "from" > or "of" it? Also, do we need the word "type" in the pk-as-rep description? > > I'm not entirely sure why we need an extension marker in KDFAlgorithmId > (since we could just allocate new OIDs for the specific parameters/etc. we > would otherwise want to put in), but I don't object to it. > > If the supportedKDFs field is not present in the request, the kdf > field in the reply MUST be absent. > > Somehwere in here we should probably say that if the supportedKDFs field is > absent, implementations continue to use the RFC 4556 KDF (if they continue > at all). > > If the client fills the supportedKDFs field in the request, but the > kdf field in the reply is not present, the client can deduce that the > KDC is not updated to conform with this specification. In that case, > it is a matter of local policy on the client whether to reject the > reply when the kdf field is absent in the reply. > > I think we need to mention that this implies the server is using the old, > insecure KDF function or that there is an active downgrade attack, and that > the expected steady state is to reject this reply as a downgrade attack. > > Section 7.1 > > We may get someone asking us to use RFC 6761 example domain names instead > of SU.SE in the examples, but I don't see a need to go through the effort > of regenerating the test vectors right now as a precaution. > > Section 8 > > This document describes negotiation of checksum types, key derivation > functions and other cryptographic functions. If negotiation is done > unauthenticated, care MUST be taken to accept only acceptable values. > > nit: I'd suggest rephrasing as "If a given negotiation is unauthenticated, > care must be taken to accept only secure values; to do otherwise allows a > MITM to perform a downgrade attack". > > > Thanks for all the good work on this document! Hopefully we can get it > across the finish line soon. > > -Ben >