From nobody Fri Mar 1 00:37:08 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 1D97412D4F0; Fri, 1 Mar 2019 00:36:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christer Holmberg To: Cc: kitten@ietf.org, ietf@ietf.org, draft-ietf-kitten-pkinit-alg-agility.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155142941301.6207.9229636209459945659@ietfa.amsl.com> Date: Fri, 01 Mar 2019 00:36:53 -0800 Archived-At: Subject: [kitten] Genart last call review of draft-ietf-kitten-pkinit-alg-agility-05 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: Fri, 01 Mar 2019 08:36:53 -0000 Reviewer: Christer Holmberg 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 treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-kitten-pkinit-alg-agility-05 Reviewer: Christer Holmberg Review Date: 2019-03-01 IETF LC End Date: 2019-02-17 IESG Telechat date: 2019-03-07 Summary: The draft needs to be more clear on how RFC 4556 is updated. Major issues: None Minor issues: Q1: For the unfamiliar reader, it is unclear exactly how RFC 4556 is updated. There is e.g., no text indicating what sections of 4556 are updated, and there is no "Updates to RFC 4556" section. I assume the remainder of the draft then updates RFC 4556, but I think it needs to be more clear for the unfamiliar reader. Even if a "Updates to RFC 4556" section would not be feasible, the document should indicate what parts/sections of 4556 are updated, and what sections in the draft defines those updates. Nits/editorial comments: Q2: Both the Abstract and the Introduction start with "This document updates PKINIT,..." I think it would be good to first give some background information on the issue(s), and then state that the document fixes those issues by updating RFC 4556. From nobody Tue Mar 5 18:59: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 0B1E512F1AB; Tue, 5 Mar 2019 18:59:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Datatracker on behalf of Ben Campbell To: "The IESG" Cc: draft-ietf-kitten-pkinit-alg-agility@ietf.org, Robbie Harwood , kitten-chairs@ietf.org, rharwood@redhat.com, kitten@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155184118500.27640.6627144618336578521.idtracker@ietfa.amsl.com> Date: Tue, 05 Mar 2019 18:59:45 -0800 Archived-At: Subject: [kitten] Ben Campbell's No Objection on draft-ietf-kitten-pkinit-alg-agility-05: (with COMMENT) 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, 06 Mar 2019 02:59:45 -0000 Ben Campbell has entered the following ballot position for draft-ietf-kitten-pkinit-alg-agility-05: 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-pkinit-alg-agility/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, thanks for this work. I only have a couple of editorial comments: - Abstract and Introduction: Please expand PKINIT on first mention in both the abstract and body. §4: "... implementations conforming to this specification can OPTIONALLY send back a list of supported CMS types ..." OPTIONALLY is not a defined keywords. I suggest changing "... can OPTIONALLY ..." to "MAY" Plural disagreement between "implementations" and "a list". From nobody Wed Mar 6 00:28:54 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 C3FBB124408; Wed, 6 Mar 2019 00:28:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Datatracker on behalf of Adam Roach To: "The IESG" Cc: draft-ietf-kitten-pkinit-alg-agility@ietf.org, Robbie Harwood , kitten-chairs@ietf.org, rharwood@redhat.com, kitten@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155186093172.24680.5838326300642921223.idtracker@ietfa.amsl.com> Date: Wed, 06 Mar 2019 00:28:51 -0800 Archived-At: Subject: [kitten] Adam Roach's Discuss on draft-ietf-kitten-pkinit-alg-agility-05: (with DISCUSS and COMMENT) 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, 06 Mar 2019 08:28:52 -0000 Adam Roach has entered the following ballot position for draft-ietf-kitten-pkinit-alg-agility-05: 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-pkinit-alg-agility/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks to everyone who has worked on this over the past several years. I have one "discuss DISCUSS" that I suspect may be a misunderstanding on my part about how Kerberos deals with OIDs in general. If so, please bear with my ignorance. I just want to make sure something important isn't being overlooked. I can see in https://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-26 that the OID 1.3.6.1.5.2 has been reserved for Kerberos v5 objects (a reservation that appears to have been copied out of RFC 1700). I also see that RFC 4556 uses 1.3.6.1.5.2.3 and defines three nodes (.1, .2, and .3) underneath it. Try as I might, I can't find any plausibly authoritative registry that tracks the reservation of 1.3.6.1.5.2.3, or of its children 1.3.6.1.5.2.3.1, 1.3.6.1.5.2.3.2, and 1.3.6.1.5.2.3.3. This document then defines the use of 1.3.6.1.5.2.3.6. How do we know that "6" is free? How will future specifications know that "6" is no longer available? This document also defines 1.3.6.1.5.2.3.6.1, 1.3.6.1.5.2.3.6.2, 1.3.6.1.5.2.3.6.3, and 1.3.6.1.5.2.3.6.4 for the various hash algorithms. Assuming this list continues to be added to, how will future specifications avoid collisions? I have a similar question about 1.3.6.1.5.2.4.5.1. I think my confusion stems from the fact that I was under the impression that everything under 1.3.6.1 was managed by IANA -- at least, that's my reading of RFC 1155. To be clear: if I understand the situation correctly, I recognize that there may be a bigger problem here that is beyond the remit of this document to solve; however, I think it would be reasonable to not make the existing problem worse. In particular -- and again, I may simply be confused here -- I would expect this document to at least ask IANA to create a table at https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml that keeps track of the children of 1.3.6.1.5.2.3.6. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- §4: > When the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned > as described in Section 3.2.2 of [RFC4556], implementations > conforming to this specification can OPTIONALLY send back a list of The term "OPTIONALLY" is not defined in RFC 2119, although I believe the intention of this passage is to make a normative statement consistent with the RFC 2119 definition of "MAY" / "OPTIONAL". Unfortunately, we only get an auxiliary verb and an adjective from RFC 2119... no adverbs. Please rephrase to use "OPTIONAL" or "MAY". --------------------------------------------------------------------------- §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], implementations conforming > to this specification can OPTIONALLY send a list of digest algorithms Same comment as above. From nobody Wed Mar 6 08:57:21 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 7E07513103B; Wed, 6 Mar 2019 08:57:19 -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 2Qg7_Hf1zcRj; Wed, 6 Mar 2019 08:57:16 -0800 (PST) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700135.outbound.protection.outlook.com [40.107.70.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45716130F46; Wed, 6 Mar 2019 08:55:06 -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=7kEFEk9CRc66zczxCiQFBrXpOay0dGTIyB0QbzhiiVc=; b=Nu5gNLIJhvabPC09irkHivvs9mTk6mdv7HqhWqt/H9ewlMt35FUgxggRyf8RNHQB4BLzbU/J2RtD77qarnIBLhCHuILGpOc6GPN5SojF/Shi9q2lhejZI+WN5GmR60vXYQeqckTiNPv/ccmwhY3LspYYbRV20RS8HOCGB+Jbn8I= Received: from SN2PR01CA0059.prod.exchangelabs.com (2603:10b6:800::27) by BYAPR01MB4854.prod.exchangelabs.com (2603:10b6:a03:91::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.20; Wed, 6 Mar 2019 16:55:04 +0000 Received: from DM3NAM03FT007.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::202) by SN2PR01CA0059.outlook.office365.com (2603:10b6:800::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1665.18 via Frontend Transport; Wed, 6 Mar 2019 16:55:04 +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 DM3NAM03FT007.mail.protection.outlook.com (10.152.82.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13 via Frontend Transport; Wed, 6 Mar 2019 16:55:03 +0000 Received: from [18.101.8.206] (VPN-18-101-8-206.MIT.EDU [18.101.8.206]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x26Gt0NG003162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 6 Mar 2019 11:55:01 -0500 To: Datatracker on behalf of Adam Roach , The IESG CC: , Robbie Harwood , , References: <155186093172.24680.5838326300642921223.idtracker@ietfa.amsl.com> From: Greg Hudson Openpgp: preference=signencrypt Autocrypt: addr=ghudson@mit.edu; keydata= xsFNBFLMQYIBEADZLNv8Jpeo2d4XSLE+k6m1VD2iOyX66wErZKaQpYrGB/leWKfz8l6c3pWd iVUnCoyxKlhRuGVArszdh2wUSRgHnMl86JC/vIdawdOdbnlTVfOJTiP3EfycsMUUDG6GckLY e+xxo7sM/bpXpGkbIWc0Ec/vbQt67eeW2En1AqL+ezJdVN9XL8icH2Hu6HlqxGgleC5H0yAi kM4yvNjo5z2M/Dr/x63bLcIdKkSRPzd0OaBg2g0Yh651eYpPu0e1Gi6785ZBjV4bnv3K5oLo 5XsiHIZ60maHWTEyMO/byw4aS2cCWIovXurvz699KSF83B296+xhsFhhz4+kbQgXvJt4kIoI pdpX6xbIkeVlc+FuUbyE8MUGveA3TFHXZ4+0f2tvTekey/62FOeXnrqc4NsBViir3zGTXAqC 7PQTNnX/86jyW+9SnJo9XbSBB3NV0K5I2o1cDzqRPqy/4fsoq8SxQwRga0CSId1PzE9PUEUY V0FCldo9LvPsUK9YE7AuwC+bcQiVLah5TF+5Kk7yLSaRxzQ3fI5lcqk5UPUqMLa87cRBdnal niuHVg0u3W22RMPkWe2iPIYYdr4TQDzCkD2JXpXNaZ3KipVT5aqowwfPEt7b6ti0vjrOInij YzFmVNMGKYabwh2zxKWQQ8GO5mUVu09CSe33H4EW7pDP+zHr2wARAQABzR1HcmVnIEh1ZHNv biA8Z2h1ZHNvbkBtaXQuZWR1PsLBeAQTAQIAIgUCUsxBggIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AACgkQDLoIV1+Dct8dZBAA1Mtoq1RPuUQg6hL2qFjwTEXeonWq8czkQ1fNNzO9 x8I3VLn5L6CmWeAmxRU1DD0qZ5HL24+Mwnvy/eazp4/CSgiPC52KfbNsnQtg/E+8ruFQVHA/ 3HZXuCT/Nz4s06N3fMZrJLCGNEHRD0S43kb2GGboVY3ykO3FbPJB/DxDqtIMqt6B1SZ87UAR CVsRc296X3TsF9BgoQ/n54XfYAzrACkuIH9biHmH6wB1eykCeuhkCsu5Zf/tlSXJCFiuhvS+ CX2EbNKF+0MLcGAavSzbjTnQw3kv8unSgecbEQ7A8ibGx6Jwgnvy0gzu6w4prhR40pVYDcL+ sKsmQg6jo/uPvGdEqHISFSK8FxGGAonaAwg0014bXLaPo2MckcZ+szcHA/z4vpTdB1vChexL omM5ZTeSJaFfeYsspv8sq6EL1x21c7A+ngCmB70/OZR6dcgf9/ILmcjBiYfJHYukXTIvGT6y QJbok19So8RJKUYjzzHDKBweg8x6HdIrdy7HTcLzsqY9PFGg7/YlbLlGQwYXhK1b4uBmWyE7 I/402+57I1YpMYND7vsTmJuE13Gv5ZGhYn5pSzX9ZTWY13LgGymkWBXPxfefkHKTV9ROCGEL t7SV3Nf7ZsCGLRGmDT6oqLz75/IrhKEcHIfD4ct+QvIm6pvPNvikQMwPWSd52GazILLOwU0E UsxBggEQAKaz/wX8nsSUaivmwW4NVlbmTsErHUt9iNHm9CmieuoDv1o8qUqEV6RiONIs0q5Y +dcooazhHRNpjAST2rbQFBZebfpVRKYAGzHoZEQ6OV8Eao+NjAGazS8RuwIxpeZ36r3AyVhe TAIvIzwpQFDNKTIUNbXctHrZ157TlxDuKwZ3+Yw/bhQE5YGrSLm17wIMcY3UHiE1mO5X0ohR dDeTf93PignUUvWvRRQLyxRGsBLz/CCwmCJZeu/FjnDk8HkEbAlmFAJ+YZu9rQ40vU6Z40KY L5U9PIn0FdSxviK7mys+VbFYV6mXWXZN8dOkHuG6zSdmobE90G6ZzAPcI4cyql63N+kUOb3b hGI/Wvn6tUbWeIc8UvQGpYb0+eOKHQBNKUOq5RV98hZorZRCu2W2RzZSxiufyONvtonbUtYs BMdw+gqUpK0ir782lc3cKbj+X5iiyg3ZGvBmTU6FN/MiX6MnTyEwOScFboKe6vB8ZgwII85K n9qlSI3xH56JBXamMP0yqJf57q0WfP8V7lFtm8SmhU2NQyP3wRYDm2+bLTNCmRPJN2ZUgkTx c/Qjov8TeeiTfX9S3ea/GJOdgA1mQfSkmUoOWROnwDBbKGBXNzkkoJna8j/zWgo/mQ5gNdIu HXcIdDKbyyhVH3+DwxXYWyYP/pnIk3AVCss75dXcdStfABEBAAHCwV8EGAECAAkFAlLMQYIC GwwACgkQDLoIV1+Dct+oSA/9HyTkr+UQbaucXE9pP87yasObKCBxYhoeRjzBhgtYUtSDuH2o xl5M3wmTNOooQSa8R1ljhax9v02pqspIA9hyGjGjvZ6jPydDsANNcohdbMjCzXNdrCF5149w gbGQ07rkc5JNyajzxH4GE/BXclTzwTYAaHvYM5PEQLDhmubK3M/kBvjWpZxLAJAobMi/jVwQ cmai+N56X9Ht/FVIQlmCuXoMAE9ScVWFaq8JnCo9VZ0G045NcxdEoQXVUXb3E5cmZ0Ld9sUm SKSJKjYWjfE4c/8oylZuo9LDTwozBEp/jsASjL0g8F3QJsQUkFkKROd45xHcIkFulshS3xkG gMu6UduV2ypPz987f+0wdVwx+KYnmnUB83gxqVucFRxfZZXiUHUml4rJ7Ww2+//H9FFPfw9f aPMg7nLFm2T0to3pwgyisLH/aThzW3TY7CZ7gkvMDtbo9EHrN4Nl3onuOtOKQpIMbFVqX4YZ m6znSLuUiWDUd8rvQfz+4ndZKIFOG1YIKwQBV8tN1RYBGY9bhv2Wtt5X6SKIzkUhDdgeyzci MC1M3N0Pqoqrms7FdBKAd0BE7puhQ24U42APss+Ur6WyRZMQTKc41SZWfrWV30agytUVdtRu gxERw74qeGAz6o3if42vI6u30SR6OCLMMSobqKc7HQvJ2qv3Z6j9kt1zXiE= Message-ID: <7f7e80d6-2ba1-ddc9-3633-612f236e5276@mit.edu> Date: Wed, 6 Mar 2019 11:55:00 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <155186093172.24680.5838326300642921223.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(39860400002)(376002)(346002)(396003)(136003)(2980300002)(199004)(189003)(65956001)(2616005)(64126003)(186003)(106002)(786003)(316002)(36906005)(478600001)(230700001)(356004)(106466001)(58126008)(54906003)(8676002)(6306002)(53546011)(229853002)(76176011)(966005)(305945005)(31686004)(426003)(88552002)(47776003)(336012)(6706004)(956004)(446003)(2486003)(26826003)(110136005)(246002)(104016004)(2906002)(11346002)(23676004)(36756003)(65826007)(5660300002)(8936002)(126002)(486006)(4326008)(65806001)(26005)(6246003)(50466002)(86362001)(31696002)(476003)(7696005)(75432002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR01MB4854; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 67b33a34-f0e3-45d0-a7f5-08d6a2547add X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:BYAPR01MB4854; X-MS-TrafficTypeDiagnostic: BYAPR01MB4854: X-MS-Exchange-PUrlCount: 3 X-LD-Processed: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; BYAPR01MB4854; 20:Lsaw6oirVwqRopgslqHBP4pOQkLXox7//TKigKviKC5y+7r0jT4fNX3mdodsE6Xk762ZTfB4k9eULl8afD5iBXnUDPu0pIotCnxMLvDzIjLFAZsLpCyUhaFmFhcq/M29uL9dXOBC1xZd2IeaqMC5BMarg/10By8hlyEUsAFJlVH/+vyhc8RRntetLnRTUE1bdrQvli4d0kTelI/QPhpHS/rrSc+81/CBYZr2QZ1MAjqSoRwBp6gls4pVydOmRt6LxP8lHhvAZdR43eNCyrhQwsxuHHTTz1gY2hjJJE/c4ZaSZZRZvRQTLCPkzcVUzDYLdSgr8s/VL3HoLv4iu4+TBRDRMvmi1Mh8Ofuo493AQrfEFafHPAGClrQ7lxyUu7xXl4+F9ccMMXGnYxKzu4Oa/ccx0aWRiKTzbn3cM4r9kVz1zIffR2YZGCmShqJkcH2qVbAjLC3dYWPK86LduFm5KY9sDKTux3dDsUwkW0Afa1iUNbAZoWk2l/OmFfcvWIr0yJo8xxkln6oWwVhDHkkw8fVAY+LdugqN172NmoaWt5q1QGDqujWbr1IYiBiWv7yZm/R9y8SM2povj9Nps5y+fDcXwd9M2V8Onp3JSMIrD+U= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0968D37274 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWUFQUjAxTUI0ODU0OzIzOnljZnpKYzdGR2hIOXNnRXdXZlhKdTZGNkhD?= =?utf-8?B?M0dFbXYzSEJhMkk1aVFGQTNTZUZjQ2hLU2hNY0RPODhEMnBxZEt6SXlDTDJY?= =?utf-8?B?TEN1a2p1VWtkL1lybW1QNU9zUGxVVW9FSGlUYnVveUM4K3ZNN21MQzM3U2FV?= =?utf-8?B?c2RYK1d0RmdDdWtEZXZHanFmLzRSWGZaVW5UY3B2Nm9QM2pobzVZWGRVSVdu?= =?utf-8?B?VU9aTDFsblp0UVN2TjMxVXhFZW9qYWc1aGVTZ3VHNkRGcmRaVDRTdFFoM2tJ?= =?utf-8?B?RTgwWTZuTHF0NEVXK1poTitkaHFkc1R6U2JEbUxRZ0ZoelRTZEc4eVBtdUFo?= =?utf-8?B?bkxaeVNnNStOM3hPQitMTmpWWnVRWWVKWWViRjBxOXV2S09EZDNpTDdNWjkw?= =?utf-8?B?MDhyeldwTmlXVlFSOFRxNTF1NnFnQWVPWG5WaFdzVmdrQlloYmxDaEd6Zkt6?= =?utf-8?B?Z1NTYUk3Q0dOMUF5UFdZNXJmK2F4T2V6TFFkWmMybzRPSDV6ZXBPQzNodUpM?= =?utf-8?B?clhxeXJNc2pQaWNNRyt1ZGdKMkJaMUphRktLYnIydHhnTDZGVExxNTN1a2hB?= =?utf-8?B?S3NtUlZEcEw1d3BOK0JCY1M5Mi83T1JjNmV4M3VDakwySElSaVo4Mk5Qd2J2?= =?utf-8?B?QVZURjBqaitPd2J4Uk9ZYy9kY1RYdGl1a1dKMVRlUWVJaHdTbWNEdHIrbSto?= =?utf-8?B?RU56VnBqUUxMQWRheWF1eW9UQ2E5MHpyN2RWU2JIZGFBMU9nMGhjLzBZZngw?= =?utf-8?B?d09xTXFtN0lkeTVoNlhHUGNjZVlpLzIySmlxdjZ2TGRjamRXTmtCK2dWcUtZ?= =?utf-8?B?emYzdUZ5OUNIZ1FJWG9SdU1Qc0ZkWTRMK2pJODdBZGo5Q2tYdmlLaWkyaGhl?= =?utf-8?B?VitGZjZsek1TOTZBUVZxSUN2ZEF6eldCWXgwZ2d4MTVhdE9SNWtkMGdQd1BC?= =?utf-8?B?cnB6ZFFVWUlqREk4aC9rOUtOV2Q3cUZFWDVDNGJFUTV2Z0RacVJ0aEJXVjZQ?= =?utf-8?B?d3NaNkViOVpHdCtQSGprVzY5eStoZ1RJejRUb2JWQkQ5ZzBqNHdSUkxtNFhw?= =?utf-8?B?eDBCc2x5NFFObm9RU20zY0hJbjJucHB3aHR2eHlNME9nTzNJbWNkK2V5OS8v?= =?utf-8?B?cUpBb0VhVDVHa2hqeWFBc3UzQnBtTkdYcmFndW9iNEtmY0RKeG5ZNDlGTGY0?= =?utf-8?B?UTRacFNFODB4SkR2L2NxOE5YOW85czRLVXMxUEFDV3BUUTk4N0NjNVF0NVlQ?= =?utf-8?B?R21BYjRQWU9tckVMOFVPUmc0RDFRdWlUUGp0Ym84b2RZN1VUdEo1cU13ZVFF?= =?utf-8?B?SXkzdmxXTnhJcm1icmdKVXJKdFVqWjNwdGJiSU0rVFJHd0d3U0xrS1dieFNL?= =?utf-8?B?U1MwVzd0c1phQjNqUW5zOW1ieTIyMWhRUU1jZW5VREo5cVVTR2V4RFZ6K0tW?= =?utf-8?B?MWhSMUI5VU9Bc1YrQzFxQzdtUGhPQlhNU0U5dXJVMWJXOWI4V0dxOUJYLzh4?= =?utf-8?B?aGlZelJxaThvWWVCZUtwVm85M2RjMDNXU2lITGJTVW9LT25QQ2xJdiszWHJo?= =?utf-8?B?cHFNMjJlS0ZWMElsWkhWVG9GODZMWGQxZGd1QUREbVlZRXpIa2VhN2ppZG1J?= =?utf-8?B?Sk10enpncTFxT2RuU2RlK0hSYnQ3aDJzQmtYZGJZOG5TK1NtRVpNSHFTRUNo?= =?utf-8?B?WjQydHdsQ2lGSGlXWG0rUmc4KzFnZmk2ZDNnQUUxTXlYcUYxR3ZBRzBwU0xU?= =?utf-8?Q?xrMWgEll3qOvaahv8SJf98zzWjxKTKLkUmrgE=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: bu6ZTkoPM0HyQ5SLW1IfR3sANMKLFO9/lrjy+BHl/YlHIjgm/JzW5hb3C+YQxdjqyOBzTppm10yXnLZInCcXtfRh4jKSm25dOWVA2UYfwQG8fjnfx3bKHtLF7Sk8cV0JoUI26Qk/7AIw2gDJn8qKaxw27/KBJXla2yoCqRUbjv2Wt87LsOpSol1F9BEk5Nma3N5d9pMR48gXU9FkjOr9Zr3KLEauYwF0lxrHlZrzOYLQRWQFul5vUKRGHOXCAKqY4+RLZc/XVDQIvYMnPwZ5TijEzlefztfDL57BugcR+RQ/8TnHagnEEALvmFMQ0rJ1huvr99FMIsHcU/iq3jwjCnwLemlrHYb5v1uXFHY31bEYgg////EylIr7J4iz3907ADcsRo41+WC0xkrc1FAYMxf91QVOlMqtedRATJ31isg= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2019 16:55:03.6909 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 67b33a34-f0e3-45d0-a7f5-08d6a2547add 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: BYAPR01MB4854 Archived-At: Subject: Re: [kitten] Adam Roach's Discuss on draft-ietf-kitten-pkinit-alg-agility-05: (with DISCUSS and COMMENT) 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, 06 Mar 2019 16:57:19 -0000 On 3/6/19 3:28 AM, Datatracker on behalf of Adam Roach wrote: > I can see in > https://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-26 > that the OID 1.3.6.1.5.2 has been reserved for Kerberos v5 objects (a > reservation that appears to have been copied out of RFC 1700). I also see that > RFC 4556 uses 1.3.6.1.5.2.3 and defines three nodes (.1, .2, and .3) underneath > it. Try as I might, I can't find any plausibly authoritative registry that > tracks the reservation of 1.3.6.1.5.2.3, or of its children 1.3.6.1.5.2.3.1, > 1.3.6.1.5.2.3.2, and 1.3.6.1.5.2.3.3. Historically, OIDs under 1.3.6.1.5.2 have been managed out of https://web.mit.edu/kerberos/krb5-oids/krb5-oids.asn , first by Taylor Yu and more recently by myself. > This document also defines 1.3.6.1.5.2.3.6.1, 1.3.6.1.5.2.3.6.2, > 1.3.6.1.5.2.3.6.3, and 1.3.6.1.5.2.3.6.4 for the various hash algorithms. > Assuming this list continues to be added to, how will future specifications > avoid collisions? These four OIDs were not in the registry file (although their parent was included); I have added them. > I have a similar question about 1.3.6.1.5.2.4.5.1. This OID also appeared to be missing from the registry, and I have added it. > To be clear: if I understand the situation correctly, I recognize that there > may be a bigger problem here that is beyond the remit of this document to > solve; however, I think it would be reasonable to not make the existing problem > worse. In particular -- and again, I may simply be confused here -- I would > expect this document to at least ask IANA to create a table at > https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml that keeps > track of the children of 1.3.6.1.5.2.3.6. The Kerberos protocol has a history of managing some number spaces privately, and others through IANA. There was an effort to move many of those number spaces to IANA (draft-ietf-kitten-kerberos-iana-registries) but it stalled. It doesn't look like OIDs were part of that effort. From nobody Wed Mar 6 09:08:46 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 4DA951311B5; Wed, 6 Mar 2019 09:08:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Datatracker on behalf of Adam Roach To: "The IESG" Cc: draft-ietf-kitten-pkinit-alg-agility@ietf.org, Robbie Harwood , kitten-chairs@ietf.org, rharwood@redhat.com, kitten@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155189211126.358.17565788131106935834.idtracker@ietfa.amsl.com> Date: Wed, 06 Mar 2019 09:08:31 -0800 Archived-At: Subject: [kitten] Adam Roach's No Objection on draft-ietf-kitten-pkinit-alg-agility-05: (with COMMENT) 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, 06 Mar 2019 17:08:32 -0000 Adam Roach has entered the following ballot position for draft-ietf-kitten-pkinit-alg-agility-05: 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-pkinit-alg-agility/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to everyone who has worked on this over the past several years, and thanks to the authors for a timely response to my earlier discuss concerns. I am leaving the original text of my discuss below for historical reasons, as it pertains to a larger problem that would ideally be addressed by future work. --------------------------------------------------------------------------- I can see in https://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-26 that the OID 1.3.6.1.5.2 has been reserved for Kerberos v5 objects (a reservation that appears to have been copied out of RFC 1700). I also see that RFC 4556 uses 1.3.6.1.5.2.3 and defines three nodes (.1, .2, and .3) underneath it. Try as I might, I can't find any plausibly authoritative registry that tracks the reservation of 1.3.6.1.5.2.3, or of its children 1.3.6.1.5.2.3.1, 1.3.6.1.5.2.3.2, and 1.3.6.1.5.2.3.3. This document then defines the use of 1.3.6.1.5.2.3.6. How do we know that "6" is free? How will future specifications know that "6" is no longer available? This document also defines 1.3.6.1.5.2.3.6.1, 1.3.6.1.5.2.3.6.2, 1.3.6.1.5.2.3.6.3, and 1.3.6.1.5.2.3.6.4 for the various hash algorithms. Assuming this list continues to be added to, how will future specifications avoid collisions? I have a similar question about 1.3.6.1.5.2.4.5.1. I think my confusion stems from the fact that I was under the impression that everything under 1.3.6.1 was managed by IANA -- at least, that's my reading of RFC 1155. To be clear: if I understand the situation correctly, I recognize that there may be a bigger problem here that is beyond the remit of this document to solve; however, I think it would be reasonable to not make the existing problem worse. In particular -- and again, I may simply be confused here -- I would expect this document to at least ask IANA to create a table at https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml that keeps track of the children of 1.3.6.1.5.2.3.6. --------------------------------------------------------------------------- §4: > When the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned > as described in Section 3.2.2 of [RFC4556], implementations > conforming to this specification can OPTIONALLY send back a list of The term "OPTIONALLY" is not defined in RFC 2119, although I believe the intention of this passage is to make a normative statement consistent with the RFC 2119 definition of "MAY" / "OPTIONAL". Unfortunately, we only get an auxiliary verb and an adjective from RFC 2119... no adverbs. Please rephrase to use "OPTIONAL" or "MAY". --------------------------------------------------------------------------- §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], implementations conforming > to this specification can OPTIONALLY send a list of digest algorithms Same comment as above. From nobody Wed Mar 6 09:09:12 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 5806413115F; Wed, 6 Mar 2019 09:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 TQae9Qry1uql; Wed, 6 Mar 2019 09:09:01 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83F9B1311DB; Wed, 6 Mar 2019 09:08:59 -0800 (PST) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x26H8rCD055644 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 6 Mar 2019 11:08:57 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1551892139; bh=i7ddUdBbaUX/9wkdxg86Qrp1nz0UVa0eMa2tJiKeGiI=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=YbKcVSqG9ptJx3DhM92vyP3HBEj05ZasPH8IzLpYxZpVcdkr4Pa8F9z3iyfWR8cTv ywZNdmcbmkqrL34bI1ITWAlliyAEAwTXMs+2A5F48xnvfKPxLg6Vph6rLKNAQwFYiY P+CXQrcoUnihebbQr+0l9h0ZbRUkO/ZKGnlT7R1c= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Greg Hudson , Datatracker on behalf of Adam Roach , The IESG Cc: kitten@ietf.org, kitten-chairs@ietf.org, Robbie Harwood , draft-ietf-kitten-pkinit-alg-agility@ietf.org References: <155186093172.24680.5838326300642921223.idtracker@ietfa.amsl.com> <7f7e80d6-2ba1-ddc9-3633-612f236e5276@mit.edu> From: Adam Roach Message-ID: Date: Wed, 6 Mar 2019 11:08:48 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: <7f7e80d6-2ba1-ddc9-3633-612f236e5276@mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [kitten] Adam Roach's Discuss on draft-ietf-kitten-pkinit-alg-agility-05: (with DISCUSS and COMMENT) 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, 06 Mar 2019 17:09:04 -0000 Thanks for the quick response! I've cleared my discuss, as the relevant values are now registered where Kerberos registrations apparently happen at the moment. :) /a On 3/6/19 10:55 AM, Greg Hudson wrote: > On 3/6/19 3:28 AM, Datatracker on behalf of Adam Roach wrote: >> I can see in >> https://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-26 >> that the OID 1.3.6.1.5.2 has been reserved for Kerberos v5 objects (a >> reservation that appears to have been copied out of RFC 1700). I also see that >> RFC 4556 uses 1.3.6.1.5.2.3 and defines three nodes (.1, .2, and .3) underneath >> it. Try as I might, I can't find any plausibly authoritative registry that >> tracks the reservation of 1.3.6.1.5.2.3, or of its children 1.3.6.1.5.2.3.1, >> 1.3.6.1.5.2.3.2, and 1.3.6.1.5.2.3.3. > Historically, OIDs under 1.3.6.1.5.2 have been managed out of > https://web.mit.edu/kerberos/krb5-oids/krb5-oids.asn , first by Taylor > Yu and more recently by myself. > >> This document also defines 1.3.6.1.5.2.3.6.1, 1.3.6.1.5.2.3.6.2, >> 1.3.6.1.5.2.3.6.3, and 1.3.6.1.5.2.3.6.4 for the various hash algorithms. >> Assuming this list continues to be added to, how will future specifications >> avoid collisions? > These four OIDs were not in the registry file (although their parent was > included); I have added them. > >> I have a similar question about 1.3.6.1.5.2.4.5.1. > This OID also appeared to be missing from the registry, and I have added it. > >> To be clear: if I understand the situation correctly, I recognize that there >> may be a bigger problem here that is beyond the remit of this document to >> solve; however, I think it would be reasonable to not make the existing problem >> worse. In particular -- and again, I may simply be confused here -- I would >> expect this document to at least ask IANA to create a table at >> https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml that keeps >> track of the children of 1.3.6.1.5.2.3.6. > The Kerberos protocol has a history of managing some number spaces > privately, and others through IANA. There was an effort to move many of > those number spaces to IANA (draft-ietf-kitten-kerberos-iana-registries) > but it stalled. It doesn't look like OIDs were part of that effort. > From nobody Wed Mar 6 12:29:39 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 CCE6D130DC8; Wed, 6 Mar 2019 12:29:37 -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.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: kitten@ietf.org Message-ID: <155190417780.14067.3289864583575339285@ietfa.amsl.com> Date: Wed, 06 Mar 2019 12:29:37 -0800 Archived-At: Subject: [kitten] I-D Action: draft-ietf-kitten-pkinit-alg-agility-06.txt 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, 06 Mar 2019 20:29:38 -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 : PKINIT Algorithm Agility Authors : Love Hornquist Astrand Larry Zhu Margaret Wasserman Greg Hudson Filename : draft-ietf-kitten-pkinit-alg-agility-06.txt Pages : 19 Date : 2019-03-06 Abstract: This document updates the Public Key Cryptography for Initial Authentication in Kerberos standard (PKINIT) [RFC4556], to remove protocol structures tied to specific cryptographic algorithms. The PKINIT key derivation function is made negotiable, and the digest algorithms for signing the pre-authentication data and the client's X.509 certificates are made discoverable. These changes provide preemptive protection against vulnerabilities discovered in the future against any specific cryptographic algorithm, and allow incremental deployment of newer algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-pkinit-alg-agility/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-kitten-pkinit-alg-agility-06 https://datatracker.ietf.org/doc/html/draft-ietf-kitten-pkinit-alg-agility-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-pkinit-alg-agility-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 6 13:01:31 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 0FB85126C15; Wed, 6 Mar 2019 13:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 6MDrIU-DsDYn; Wed, 6 Mar 2019 13:01:13 -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 2CFA212D84D; Wed, 6 Mar 2019 13:01:12 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C177C3082E53; Wed, 6 Mar 2019 21:01:11 +0000 (UTC) Received: from localhost (ovpn-112-13.rdu2.redhat.com [10.10.112.13]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5ECD019C67; Wed, 6 Mar 2019 21:01:11 +0000 (UTC) From: Robbie Harwood To: Christer Holmberg , gen-art@ietf.org Cc: kitten@ietf.org, ietf@ietf.org, draft-ietf-kitten-pkinit-alg-agility.all@ietf.org In-Reply-To: <155142941301.6207.9229636209459945659@ietfa.amsl.com> References: <155142941301.6207.9229636209459945659@ietfa.amsl.com> Date: Wed, 06 Mar 2019 16:01:05 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Wed, 06 Mar 2019 21:01:11 +0000 (UTC) Archived-At: Subject: Re: [kitten] Genart last call review of draft-ietf-kitten-pkinit-alg-agility-05 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, 06 Mar 2019 21:01:18 -0000 --=-=-= Content-Type: text/plain Christer Holmberg writes: > Reviewer: Christer Holmberg > 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 treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-kitten-pkinit-alg-agility-05 > Reviewer: Christer Holmberg > Review Date: 2019-03-01 > IETF LC End Date: 2019-02-17 > IESG Telechat date: 2019-03-07 > > Summary: The draft needs to be more clear on how RFC 4556 is updated. > > Major issues: None > > Minor issues: > > Q1: > > For the unfamiliar reader, it is unclear exactly how RFC 4556 is updated. There > is e.g., no text indicating what sections of 4556 are updated, and there is no > "Updates to RFC 4556" section. > > I assume the remainder of the draft then updates RFC 4556, but I think it needs > to be more clear for the unfamiliar reader. > > Even if a "Updates to RFC 4556" section would not be feasible, the document > should indicate what parts/sections of 4556 are updated, and what sections in > the draft defines those updates. > > Nits/editorial comments: > > Q2: > > Both the Abstract and the Introduction start with "This document updates > PKINIT,..." > > I think it would be good to first give some background information on the > issue(s), and then state that the document fixes those issues by updating RFC > 4556. Hi Christer, thanks for your review. Greg has created and uploaded a new version (-06) to the tracker that hopefully addresses your concerns. Thanks, --Robbie --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAlyANREACgkQJTL5F2qV pEImgA/+NH40R9WSQmvD9/PXQM8+e/QXy7oX7wulwICrJ8d8aX2XNzzeP4aAWgRo ssJrL3ubBuJ4UCU0EeUdr4LLLZMgZqNY+rQIXybAFm6gRGIZC7fFy/v6X7kA+e38 WSX0BPnz0oUPmaXMi9LaKlZlOzcyutk0acOA98NjTrwdd9A90aLGbEOFrgGynJuH mZTiEJ1dLNQSvtBi3zsuezVpU3ejXi3i47tUWbv7zGyhkcBPOEr7v8He+U7ejjH6 hqZYTWj8oghwY6ZLPQ6Eo4ximwdQeh5oarFsQYlVmLgp+hONsdhUe8r+DCpwb7aE OE3ICKTkpYPodk3cWJ2QtxtUm+EdPHQjL0EmuglsHa6ZbGGRox8q8JJMivfxp1Sn RpyJ7zhXttXzf2UoJIv86WZ0lFXwwKRV7HDt0tq73QKbdWLBq/fSHPIM3a+Wdnc3 SF+eyjSSH4oZFOpU57EDINQeQVj3xA9yjht6d1RhCHTw4yVJ9xKixZVJ9hpFcnHU qD98kqIyQpG74IlmF8bBdut1e2M/pboTJvc/ngpmP0u2Lle0VilPNOt7dhR9P5rJ ROSi72cM9hj+xmN0wSpfvr6KQSmMbcY1Dgr3RC4FK1HxAQTMs6y+GyqFCvjjsAJe X2SITcSCrm0CCqWFRSvI0GmquI9JDv98DbAxBgTjIFQgNrLpKuk= =Hasg -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 6 13:06:30 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 A0300126F72; Wed, 6 Mar 2019 13:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 pvX1ikjuspXv; Wed, 6 Mar 2019 13:06:22 -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 9ACEC126C15; Wed, 6 Mar 2019 13:06:22 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4C22BA70E; Wed, 6 Mar 2019 21:06:22 +0000 (UTC) Received: from localhost (ovpn-112-13.rdu2.redhat.com [10.10.112.13]) by smtp.corp.redhat.com (Postfix) with ESMTP id 118AF19C4F; Wed, 6 Mar 2019 21:06:21 +0000 (UTC) From: Robbie Harwood To: Datatracker on behalf of Ben Campbell , The IESG Cc: draft-ietf-kitten-pkinit-alg-agility@ietf.org, kitten-chairs@ietf.org, kitten@ietf.org In-Reply-To: <155184118500.27640.6627144618336578521.idtracker@ietfa.amsl.com> References: <155184118500.27640.6627144618336578521.idtracker@ietfa.amsl.com> Date: Wed, 06 Mar 2019 16:06:21 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 06 Mar 2019 21:06:22 +0000 (UTC) Archived-At: Subject: Re: [kitten] Ben Campbell's No Objection on draft-ietf-kitten-pkinit-alg-agility-05: (with COMMENT) 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, 06 Mar 2019 21:06:24 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ben Campbell writes: > Hi, thanks for this work. I only have a couple of editorial comments: > > - Abstract and Introduction: Please expand PKINIT on first mention in bot= h the > abstract and body. > > =C2=A74: "... implementations conforming to this specification can OPTION= ALLY send > back a list of supported CMS types ..." > > OPTIONALLY is not a defined keywords. I suggest changing "... can OPTIONA= LLY > ..." to "MAY" Plural disagreement between "implementations" and "a list". Hi Ben, thanks for taking a look! Greg was kind enough to push a new version (-06) to the datatracker that hopefully addresses your concerns. Thanks, =2D-Robbie --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAlyANk0ACgkQJTL5F2qV pEKNMQ//eOy7NZu85X3iB7qaitCK0BTpsZ0IBreY62j2kKhgcK7oF42XM+hPv/ny TNdbV05bQKrz1fXJGIFld8GNaQ87A9LCFKuxMF1/3TG5+7skkyNCvDoe7QM/FX9l vBRtG3bRLdWWpf5jXx5dIRHQMSpBjANOMLVxy++zQoYIaZZYdoe9puVg93x7DJCf Hijl66qzSMR/EZOEJExiDJNZ1mxXH9Fe2gjsAiiELtkXikrSfEZNSLqImt1U8++w HthEK19MmE6cuIC3S+AGThUjrrKKciyVOLo8T63lnFwVY2t38+VtOi1ijsaLihw+ 3F3zLO/gkBp+HaS9DuGq490dciRh/BbwhNyTmMeJ9O2ihvYRJUE76R1A3aB/LPQe e83Y7Ta4U+U9noNgxfb6xbjuhSAuX4EFjf0jxGfmfC+lFmMrG3xBV3zCjF0mYWNJ m4B73vq+JOP5uCsbptZ1JUGsP7nBC7Ykl+f6oBGz5X0c4MrTh7Rr5Tm32uFPv1PN YnlRTsnTkxsSiHDCXGlyQr24RWNDgC3coLmbflPmPtO05S3upxJ+n5Z3dtUZpmsI S6hUX2+5YCKL9qxv689HyUh1B3kMzFu09oqmdd+gAkw/q8mhzjBJi1Tqml5A+zXu kWlXyXjbhZQQYub3HTbSqVHI5nrUmxzXzD8v4vlzZ90Whmg+by8= =x4J3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 6 19:29:05 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 5FA72128CB7; Wed, 6 Mar 2019 19:28:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=cooperw.in header.b=taqeSD8q; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=k2LnygQV 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 EFY1iw87Wfg2; Wed, 6 Mar 2019 19:28:49 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05F35124C04; Wed, 6 Mar 2019 19:28:49 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 5511B22F5B; Wed, 6 Mar 2019 22:28:48 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 06 Mar 2019 22:28:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm2; bh=7QXfL72BuoaFdaKn6IL1BGq XaFbP+ctBCSnvbW5yvbA=; b=taqeSD8qKj3pvzmA4ZOlw0oKoKDURznaCcZuFx3 Qvy7ulzNU+wcYzTRFdQHfA1eP+ZOyGUk1VabaefeDHiLDnhhKAsafp/R5lL9NBqQ CKaLpsw69EAytMK/7MEH1VIsXUNBKO9tJFVLkQ2zfUj2ceXaxIub1KIMyES0Bu2J RvrH0PmngKeZDZNEfmJ0o9Cf8gUjSMzOz07x5wqKyOmarsYYPsKkcJ1a9lI0elfA spLKqd0gLaydWS5EmhGFx9QM0hvfwKbN3WQd1oi5xbyR+Alj2iU8vPgbeF+YBW8X 6MojGKp9KlMI9abmQ6pX69knQk3DSd3TzG1nDQrxOzGmRhg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=7QXfL7 2BuoaFdaKn6IL1BGqXaFbP+ctBCSnvbW5yvbA=; b=k2LnygQVU4zZVAc9sNA8R7 EXFCne/SSGAdmYEV69elrKk77luAVaJRtbbvmPZeH0aeQeVsusUGvY9ukDR2Dfax LnePMOQPjbbK1BeOM+VpivXePb9gxbgYjmRJuhjYabumvYighNRwXKjF+90nqJl4 k6efs4i/hwzNfJmeLPQB2RBtIjBYpCDcynVAAedwA1bkG86phwv0/A8gkxkRGxHt lj5HpiavBmXZ5FcomMTVgSPNuFBag74jQsrpJWMfh+dzxs76mhdbnigZIZjPFghA wbBuj4fRwubRl1T7I7yNj/AO16gJM0WCfhpnTQQifOATY5qBvpWdLrIS7EUqeMkQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrfeejgdeitdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtvdenucfhrhhomheptehlihhsshgr ucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrghinh epihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrjeegnecurfgrrhgrmhep mhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsthgvrh fuihiivgeptd X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.74]) by mail.messagingengine.com (Postfix) with ESMTPA id CC222100E5; Wed, 6 Mar 2019 22:28:46 -0500 (EST) From: Alissa Cooper Message-Id: <486D3AB5-43B2-4CF6-90FB-C0F9CE534DEE@cooperw.in> Content-Type: multipart/alternative; boundary="Apple-Mail=_DCA4267F-6234-4649-A796-E993BB3B86D9" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 6 Mar 2019 22:28:44 -0500 In-Reply-To: Cc: Brian E Carpenter , General Area Review Team , kitten@ietf.org, IETF , draft-ietf-kitten-pkinit-alg-agility.all@ietf.org To: Robbie Harwood , Christer Holmberg References: <155142941301.6207.9229636209459945659@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [kitten] [Gen-art] Genart last call review of draft-ietf-kitten-pkinit-alg-agility-05 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: Thu, 07 Mar 2019 03:28:51 -0000 --Apple-Mail=_DCA4267F-6234-4649-A796-E993BB3B86D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Christer, thank you for your review. Robbie and Greg, thanks for your = responses. I entered a No Objection ballot. Alissa > On Mar 6, 2019, at 4:01 PM, Robbie Harwood = wrote: >=20 > Christer Holmberg > writes: >=20 >> Reviewer: Christer Holmberg >> 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 treat these comments just >> like any other last call comments. >>=20 >> For more information, please see the FAQ at >>=20 >> . >>=20 >> Document: draft-ietf-kitten-pkinit-alg-agility-05 >> Reviewer: Christer Holmberg >> Review Date: 2019-03-01 >> IETF LC End Date: 2019-02-17 >> IESG Telechat date: 2019-03-07 >>=20 >> Summary: The draft needs to be more clear on how RFC 4556 is updated. >>=20 >> Major issues: None >>=20 >> Minor issues: >>=20 >> Q1: >>=20 >> For the unfamiliar reader, it is unclear exactly how RFC 4556 is = updated. There >> is e.g., no text indicating what sections of 4556 are updated, and = there is no >> "Updates to RFC 4556" section. >>=20 >> I assume the remainder of the draft then updates RFC 4556, but I = think it needs >> to be more clear for the unfamiliar reader. >>=20 >> Even if a "Updates to RFC 4556" section would not be feasible, the = document >> should indicate what parts/sections of 4556 are updated, and what = sections in >> the draft defines those updates. >>=20 >> Nits/editorial comments: >>=20 >> Q2: >>=20 >> Both the Abstract and the Introduction start with "This document = updates >> PKINIT,..." >>=20 >> I think it would be good to first give some background information on = the >> issue(s), and then state that the document fixes those issues by = updating RFC >> 4556. >=20 > Hi Christer, thanks for your review. >=20 > Greg has created and uploaded a new version (-06) to the tracker that > hopefully addresses your concerns. >=20 > Thanks, > --Robbie > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art = --Apple-Mail=_DCA4267F-6234-4649-A796-E993BB3B86D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Christer, thank you for your review. Robbie and Greg, thanks = for your responses. I entered a No Objection ballot.

Alissa

On Mar = 6, 2019, at 4:01 PM, Robbie Harwood <rharwood@redhat.com>= wrote:

Christer Holmberg <christer.holmberg@ericsson.com> writes:

Reviewer: Christer Holmberg
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 = treat these comments just
like any other last call = comments.

For more information, please see = the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: = draft-ietf-kitten-pkinit-alg-agility-05
Reviewer: Christer = Holmberg
Review Date: 2019-03-01
IETF LC End = Date: 2019-02-17
IESG Telechat date: 2019-03-07

Summary: The draft needs to be more clear on = how RFC 4556 is updated.

Major issues: = None

Minor issues:

Q1:

For the unfamiliar reader, = it is unclear exactly how RFC 4556 is updated. There
is = e.g., no text indicating what sections of 4556 are updated, and there is = no
"Updates to RFC 4556" section.

I assume the remainder of the draft then updates RFC 4556, = but I think it needs
to be more clear for the unfamiliar = reader.

Even if a "Updates to RFC 4556" = section would not be feasible, the document
should = indicate what parts/sections of 4556 are updated, and what sections = in
the draft defines those updates.

Nits/editorial comments:

Q2:

Both the Abstract and the Introduction start = with "This document updates
PKINIT,..."

I think it would be good to first give some background = information on the
issue(s), and then state that the = document fixes those issues by updating RFC
4556.

Hi Christer, thanks for your review.

Greg has created and uploaded a = new version (-06) to the tracker that
hopefully addresses your concerns.

Thanks,
--Robbie
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

= --Apple-Mail=_DCA4267F-6234-4649-A796-E993BB3B86D9-- From nobody Thu Mar 7 17:46:46 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 15A5D13120D for ; Thu, 7 Mar 2019 17:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 Yg-p7zvI14s8 for ; Thu, 7 Mar 2019 17:46:42 -0800 (PST) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C03D1311E8 for ; Thu, 7 Mar 2019 17:46:42 -0800 (PST) Received: from mail08.wdf.sap.corp (mail01.sap.corp [194.39.131.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 44Fr2S2CD5zyQ3; Fri, 8 Mar 2019 02:46:40 +0100 (CET) X-purgate-ID: 152705::1552009600-00000213-606B97AF/0/0 X-purgate-size: 3675 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail08.wdf.sap.corp (Postfix) with ESMTPS id 44Fr2S0Rqfz30Vl; Fri, 8 Mar 2019 02:46:40 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 073E2404C; Fri, 8 Mar 2019 02:46:40 +0100 (CET) In-Reply-To: References: To: Sam Hartman Date: Fri, 8 Mar 2019 02:46:40 +0100 (CET) CC: kitten@ietf.org Reply-To: mrex@sap.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20190308014640.073E2404C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [kitten] Review of draft-ietf-kitten-channel-bound-flag-04 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: Fri, 08 Mar 2019 01:46:45 -0000 Just a quick comment, I haven't been following IETF work for months... Sam Hartman wrote: > > This draft is based on the premis that the GSS-API channel binding > behavior is flawed and that there's a security problem associated with > not knowing if channel bindings are validated. Frankly, the whole idea of channel bindings is thoroughly flawed, and it _can_not_possibly_work_ whenever there are any application level gateways ("proxies") involved in the communication path, something that is pretty common in non-trivial application, and in particular in non-trivial backend servers. If you see someone using channel bindings, you can be pretty sure that they're doing some kind of seriously stupid abuse of technology. Whenever the *ENTIRE* application-level data is properly protected with gss_wrap(conf=TRUE), channel bindings will provide *ZERO* additional value, while creating a whole bunch of problems. > > I've heard this argument over the years, but never been convinced of it, > and unfortunately, this draft is filled with assertions of that fact > without any rationale. I agree, this is extremely disappointing. In particular, because a general need is asserted, although just the opposite is true, for honest and sane usage scenarios, channel bindings are useless bloat that break application level proxy traversal. > > At one level it doesn't matter much. I absolutely agree that a facility > for knowing if channel bindings are validated would be incredibly useful > and would simplify application design. That is what the "ret_flags" could be used for. There are still a few free bits left in the 32-bit output value of the rfc2744 C-bindings. > > As I write this up, I'm realizing that the draft authors seem to be > making an assumption that there are applications in the wild that pass > in channel bindings to the initiator but not the acceptor or vise > versa. The only such application I'm aware of is gss ftp, which passed > IP address channel bindings into the acceptor and optionally initiator. Yes, apparently there are. The application that I am aware of is Microsoft's proprietary Hack rfc4559 HTTP Negotiate when used with Kerberos, where TLS channel bindings are first asserted in Windows Vista (or Win7) ? But rfc4559 is a crystal clear HACK, which misuses a naked rfc1964/rfc4121 two-token Kerberos authentication as an OTP scheme, and by NOT using any of the GSS-API message protection facilities for the application data, there is *NO* binding between the application data in the HTTP request and the AP_REQ in the rfc4559 HTTP Request header, making that approach vulnerable to man-in-the-middle attacks (proxying/relaying). However, if the backend architecture uses a reverse proxy (Load Balancer / "SSL-Accelerator"), while the HTTP-layer rfc4559 processing is performed in the backend host (different machine), it is simply not possible to perform channel binding to the TLS channel (that ended on the reverse proxy). > > It would help me evaluate whether there is a security problem to > understand these applications better. > I note that SASL is not such an application. There is a serious security problem in rfc4559 HTTP negotiate. Use of TLS channel bindings for rfc4559 is a mitigation to pretend that the security problem doesn't exist. > > Regardless of whether this is a security problem, I am very supportive > of a mechanism along these lines. I think that it would simplify > application design over the approaches necessary for the gs2 family of > mechanisms. -Martin From nobody Sun Mar 10 21:26:10 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 A39A612F19D for ; Sun, 10 Mar 2019 21:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 TGIpnnf2kQvJ for ; Sun, 10 Mar 2019 21:26:05 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820139.outbound.protection.outlook.com [40.107.82.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E55C12008A for ; Sun, 10 Mar 2019 21:26:05 -0700 (PDT) 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=OIOoUxmww0ift1G/a0quqq/WRLjHW6o7Nsmu+aWogIQ=; b=Bvr3IQBYSyp+LLZpY0XiPJov5eXA+sybBBX8xNbri03vHPP8fZGCWCtQI5ZnHKcvbkI+eViTmMEBr6zsEetgaf47WH83CNd39HHjN8wlf/Y65J61x2+7JCZ4ShIcznHTRAuv5cHkYYSbUhyUXgTefgZLjZSweYkdTO6hVkZAMOE= Received: from SN6PR0102CA0030.prod.exchangelabs.com (2603:10b6:805:1::43) by BL0PR0102MB3585.prod.exchangelabs.com (2603:10b6:207:1b::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.18; Mon, 11 Mar 2019 04:26:03 +0000 Received: from CO1NAM03FT038.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::207) by SN6PR0102CA0030.outlook.office365.com (2603:10b6:805:1::43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.18 via Frontend Transport; Mon, 11 Mar 2019 04:26:02 +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 CO1NAM03FT038.mail.protection.outlook.com (10.152.81.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.19 via Frontend Transport; Mon, 11 Mar 2019 04:26:01 +0000 Received: from [18.101.8.116] (VPN-18-101-8-116.MIT.EDU [18.101.8.116]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x2B4PvHj023651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 11 Mar 2019 00:26:00 -0400 References: <20190308014640.073E2404C@ld9781.wdf.sap.corp> To: From: Greg Hudson Openpgp: preference=signencrypt Autocrypt: addr=ghudson@mit.edu; keydata= xsFNBFLMQYIBEADZLNv8Jpeo2d4XSLE+k6m1VD2iOyX66wErZKaQpYrGB/leWKfz8l6c3pWd iVUnCoyxKlhRuGVArszdh2wUSRgHnMl86JC/vIdawdOdbnlTVfOJTiP3EfycsMUUDG6GckLY e+xxo7sM/bpXpGkbIWc0Ec/vbQt67eeW2En1AqL+ezJdVN9XL8icH2Hu6HlqxGgleC5H0yAi kM4yvNjo5z2M/Dr/x63bLcIdKkSRPzd0OaBg2g0Yh651eYpPu0e1Gi6785ZBjV4bnv3K5oLo 5XsiHIZ60maHWTEyMO/byw4aS2cCWIovXurvz699KSF83B296+xhsFhhz4+kbQgXvJt4kIoI pdpX6xbIkeVlc+FuUbyE8MUGveA3TFHXZ4+0f2tvTekey/62FOeXnrqc4NsBViir3zGTXAqC 7PQTNnX/86jyW+9SnJo9XbSBB3NV0K5I2o1cDzqRPqy/4fsoq8SxQwRga0CSId1PzE9PUEUY V0FCldo9LvPsUK9YE7AuwC+bcQiVLah5TF+5Kk7yLSaRxzQ3fI5lcqk5UPUqMLa87cRBdnal niuHVg0u3W22RMPkWe2iPIYYdr4TQDzCkD2JXpXNaZ3KipVT5aqowwfPEt7b6ti0vjrOInij YzFmVNMGKYabwh2zxKWQQ8GO5mUVu09CSe33H4EW7pDP+zHr2wARAQABzR1HcmVnIEh1ZHNv biA8Z2h1ZHNvbkBtaXQuZWR1PsLBeAQTAQIAIgUCUsxBggIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AACgkQDLoIV1+Dct8dZBAA1Mtoq1RPuUQg6hL2qFjwTEXeonWq8czkQ1fNNzO9 x8I3VLn5L6CmWeAmxRU1DD0qZ5HL24+Mwnvy/eazp4/CSgiPC52KfbNsnQtg/E+8ruFQVHA/ 3HZXuCT/Nz4s06N3fMZrJLCGNEHRD0S43kb2GGboVY3ykO3FbPJB/DxDqtIMqt6B1SZ87UAR CVsRc296X3TsF9BgoQ/n54XfYAzrACkuIH9biHmH6wB1eykCeuhkCsu5Zf/tlSXJCFiuhvS+ CX2EbNKF+0MLcGAavSzbjTnQw3kv8unSgecbEQ7A8ibGx6Jwgnvy0gzu6w4prhR40pVYDcL+ sKsmQg6jo/uPvGdEqHISFSK8FxGGAonaAwg0014bXLaPo2MckcZ+szcHA/z4vpTdB1vChexL omM5ZTeSJaFfeYsspv8sq6EL1x21c7A+ngCmB70/OZR6dcgf9/ILmcjBiYfJHYukXTIvGT6y QJbok19So8RJKUYjzzHDKBweg8x6HdIrdy7HTcLzsqY9PFGg7/YlbLlGQwYXhK1b4uBmWyE7 I/402+57I1YpMYND7vsTmJuE13Gv5ZGhYn5pSzX9ZTWY13LgGymkWBXPxfefkHKTV9ROCGEL t7SV3Nf7ZsCGLRGmDT6oqLz75/IrhKEcHIfD4ct+QvIm6pvPNvikQMwPWSd52GazILLOwU0E UsxBggEQAKaz/wX8nsSUaivmwW4NVlbmTsErHUt9iNHm9CmieuoDv1o8qUqEV6RiONIs0q5Y +dcooazhHRNpjAST2rbQFBZebfpVRKYAGzHoZEQ6OV8Eao+NjAGazS8RuwIxpeZ36r3AyVhe TAIvIzwpQFDNKTIUNbXctHrZ157TlxDuKwZ3+Yw/bhQE5YGrSLm17wIMcY3UHiE1mO5X0ohR dDeTf93PignUUvWvRRQLyxRGsBLz/CCwmCJZeu/FjnDk8HkEbAlmFAJ+YZu9rQ40vU6Z40KY L5U9PIn0FdSxviK7mys+VbFYV6mXWXZN8dOkHuG6zSdmobE90G6ZzAPcI4cyql63N+kUOb3b hGI/Wvn6tUbWeIc8UvQGpYb0+eOKHQBNKUOq5RV98hZorZRCu2W2RzZSxiufyONvtonbUtYs BMdw+gqUpK0ir782lc3cKbj+X5iiyg3ZGvBmTU6FN/MiX6MnTyEwOScFboKe6vB8ZgwII85K n9qlSI3xH56JBXamMP0yqJf57q0WfP8V7lFtm8SmhU2NQyP3wRYDm2+bLTNCmRPJN2ZUgkTx c/Qjov8TeeiTfX9S3ea/GJOdgA1mQfSkmUoOWROnwDBbKGBXNzkkoJna8j/zWgo/mQ5gNdIu HXcIdDKbyyhVH3+DwxXYWyYP/pnIk3AVCss75dXcdStfABEBAAHCwV8EGAECAAkFAlLMQYIC GwwACgkQDLoIV1+Dct+oSA/9HyTkr+UQbaucXE9pP87yasObKCBxYhoeRjzBhgtYUtSDuH2o xl5M3wmTNOooQSa8R1ljhax9v02pqspIA9hyGjGjvZ6jPydDsANNcohdbMjCzXNdrCF5149w gbGQ07rkc5JNyajzxH4GE/BXclTzwTYAaHvYM5PEQLDhmubK3M/kBvjWpZxLAJAobMi/jVwQ cmai+N56X9Ht/FVIQlmCuXoMAE9ScVWFaq8JnCo9VZ0G045NcxdEoQXVUXb3E5cmZ0Ld9sUm SKSJKjYWjfE4c/8oylZuo9LDTwozBEp/jsASjL0g8F3QJsQUkFkKROd45xHcIkFulshS3xkG gMu6UduV2ypPz987f+0wdVwx+KYnmnUB83gxqVucFRxfZZXiUHUml4rJ7Ww2+//H9FFPfw9f aPMg7nLFm2T0to3pwgyisLH/aThzW3TY7CZ7gkvMDtbo9EHrN4Nl3onuOtOKQpIMbFVqX4YZ m6znSLuUiWDUd8rvQfz+4ndZKIFOG1YIKwQBV8tN1RYBGY9bhv2Wtt5X6SKIzkUhDdgeyzci MC1M3N0Pqoqrms7FdBKAd0BE7puhQ24U42APss+Ur6WyRZMQTKc41SZWfrWV30agytUVdtRu gxERw74qeGAz6o3if42vI6u30SR6OCLMMSobqKc7HQvJ2qv3Z6j9kt1zXiE= Message-ID: <9bed7e51-4ba6-49fb-f1b1-722121317bdf@mit.edu> Date: Mon, 11 Mar 2019 00:25:57 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20190308014640.073E2404C@ld9781.wdf.sap.corp> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(39860400002)(346002)(376002)(136003)(396003)(2980300002)(199004)(189003)(6916009)(36906005)(64126003)(58126008)(316002)(246002)(486006)(786003)(305945005)(106466001)(50466002)(88552002)(36756003)(2351001)(229853002)(478600001)(26826003)(106002)(6666004)(356004)(2906002)(8676002)(31686004)(14444005)(956004)(76176011)(75432002)(65956001)(47776003)(11346002)(8936002)(476003)(65826007)(26005)(5660300002)(230700001)(31696002)(336012)(186003)(446003)(426003)(23676004)(2486003)(6706004)(104016004)(6246003)(2616005)(86362001)(65806001)(7696005)(126002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR0102MB3585; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 627982db-3623-46b4-e6b9-08d6a5d9ab7f X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:BL0PR0102MB3585; X-MS-TrafficTypeDiagnostic: BL0PR0102MB3585: X-Microsoft-Exchange-Diagnostics: 1; BL0PR0102MB3585; 20:Td9YtRzOxYpiBquIBnZLwvabXK8VkGFFVOITb3WZ3xG0z3eWAQpJvc4epwZDnR4OMZOyRTNsYLRucHT7kajGDQtDCjc2pFXN0wGFNm5IyCqMqcYH3t8fHRGcaU1X8sTmnDI3fU3Ekq5E6KdFOL3gYvznALW+ZHoqRT+WNDCqah10ta67sakE8sYpJuffkZZRPaQFYIMsZ8vEytiqdFfSnNjWAAhvOeOCkdPQwyAH0kwnLTfN9JXuACgzOb7cbJ0CyyQOD3JtgQJ2kDz+6qAllWJboVN9wVoRsPqSJMWlkyB1KocSMVHo6Q/Vo4pISnxKWRN+UiskKVRIhxe6DjCELYN1E+3rh2PVfIKiC3q06n7trpzOErWT2KsPnNfUCybc7xF/if2De8tVyB82Ok0LwHvadt/t7CetefMHv9kMh5VbFK71UAYANyixhYbtfIL/XyEBdu4xPsODNYxiw/ETq6V3Qa4nG7glgyYHwlfEar5rmGIM3knPxZMu719b3yPOUe/2wipwEbhZ+xd5ECiZbjcyS+M0gCikNobmGDSPm1ETIimRy33qTlhHDDmqNMZRUJbf4eCZyIoavEsgWWn7Btkw77qfcX/GqdknKBrxJOw= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 09730BD177 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTDBQUjAxMDJNQjM1ODU7MjM6VVJidXI4NFFPVUhHMkJrRW1DUDFkL0FJ?= =?utf-8?B?Y3o1N2pkcUJuZDhOM3lpSS9xNnFzRXVwSDlHbzF1d2N1RzVvSjNVUENKQ1FW?= =?utf-8?B?L3p6UkUyMytPa2FwU2FrR3RlMnJhN2RIT2xzMDNIZDBjWitOakJPUEpSSEJC?= =?utf-8?B?N2I2ZmZ5aDJCaStEVVk3WFRaa3R6Z0tINkhwY0ZydkhqL1EvZW5yMHRrUVVR?= =?utf-8?B?bXE0WFNmWTB6Vlh2ZktMTXFHM0tSaDcrTHU1YUdlZ0UxWktVZlJpOVRwV1d6?= =?utf-8?B?NmVlZnZWR0FnWVNqUE9zcy9qZkloN3JZT09sUGdxSjd6VE9wMkI0QVdXQUQx?= =?utf-8?B?dzFLL0ZlcEVSazByeTRqYXA5ZG1OMTlGbU9oaHQvZnB3ZTlmNEVyeGU5ZklR?= =?utf-8?B?RFIwT1p5dXQxZGdYQndGa1BVQTd3SEg5WUtZNmRSY2RWNTMwbjFOdEpiUFc1?= =?utf-8?B?MGxlVjlaQmFZTWJRWVpKTkJiVUJMdlpjMUkxT2MyZFRZYkc3TFpKQU1TVFhl?= =?utf-8?B?c0dLTEFBS0tRMXFDc28ydkpBZDhkWFhySDd3cHlTVEJ5MGNUVmY0WnV4UFdH?= =?utf-8?B?dC83dDJLYzBxeldBejUzaVFDbCtDb1IzYms0aERzTnp6eU1FWW54ZXI2ZHU2?= =?utf-8?B?eWd6UWRzQ0N2Y2QxcVdZUDZnNUR3UitXSzVWMkdkVzdnWnVNYWdpV1RPV21K?= =?utf-8?B?UjBVNU5ETzdkQ1Zncm9xTENyTUZYeUpVUW11Qk9UeUtSWEVTa1Ezd1JNWWVw?= =?utf-8?B?NGQzZGhkaFdLRXF3ZU8xaW9kaEhEUXBURXJ6ZFp5Y3lISHErV2p1UmVRVVRu?= =?utf-8?B?aGh2TU1VRmgwbUs1S2lZZ2VTcE9sdzdJTXA3TC9zWWcxUFFPWFV0akV3OVha?= =?utf-8?B?UXcwRWQxKzV3ZFVLUkVHNmE5KzR0akJMT1ZnRmZLYU9Fb0lWREFEQzV0Ny9n?= =?utf-8?B?ejJMb1k1Y3NKL3d2Z09wZTJ1S0VGaVppMTZJUnM1UWUrc3FaTTBJc2hMWVVZ?= =?utf-8?B?MHgydzZPNnh5SXJWK0hjU0lmMk5KS3NzeCsrK2NqcVVHOS9nbFlSNXpHQXpE?= =?utf-8?B?NDN1REYvMEtmOEdsWDdTWmFKckM1OWx5WUZoTGVMMnIyRXg1R1JXeC9DcHBN?= =?utf-8?B?MmFqdUNtY2pIWWFCeFZTY0tXa2lCalV2Q3R1OUVrYWhVcVM3cE1HcW05bURm?= =?utf-8?B?aGVodDNmeUUyWERya0Y3OFdJcElhQi81dWFta2J2NGQ0MWZod1FVbzlVWWJF?= =?utf-8?B?bm5ncUdsWE10L2RqSzY1WXlwWWptMzNlTEZjN1ZIR25pYVJ5VGs0eEwxT2RQ?= =?utf-8?B?YUpQYS9Na3c4c21WdFQ5aEk1K0NFaTg2akJUNkVjT3RlV05sMnJTN3JWSXBn?= =?utf-8?B?bkUxRnlSZzlmVHhVU2t4MFN2WDIrWE1DZko4eTgwaWRMWDVjT3ROUEl2M2V1?= =?utf-8?B?bGY5M0lhS2gvVmRka2Z1ZmIydnRlRXhPdVlUaFNlU3NkTEpqS2Rpall6TXll?= =?utf-8?B?M2hPN0g4M3VSY1J0ckF6a0NqNG5oR3ZFcFhNTVEzbTRLMmFKdTJjaGkyc1lo?= =?utf-8?B?c1VPOXdjbVBuNkJVT1pmcE5CNzV0QUpITWhYOHd2WGtuWnVjRXVIQlJPSXEz?= =?utf-8?B?WTR6c2ZoUis4RzlFcm05bitPTE1ZRVU3ZFlhK3JQenI1SkJFQ0NySXJCamtk?= =?utf-8?Q?Jua8GtJq/D7hHfZdhSpAfWRLI7BNtqP57/dBjhlMM?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: DGfGLKZdzydugOOw51HSwpVZUQuf9kHgUX8bo2ChPiI0FqFVoCHGbKggrf2cS4CHBC4aRytAOxELhuCieNK0GB3FRcYtwQcoCW/YOdM9VkIyg4yFkS3K6/tAKsoy0J7AcDJ+mezIbApJwTvY1iWBbRzIXw/dtb9rL9nHgH8DXNjer/o6qAFscaVcAB0EVax3/JFd2rcpAlEbf6zk48iW0thcfglSP0Ut2c9MruQfaqcCz9WJTfTuFRLA8Ai+61svHqNwDLlQPXld22aZh59EfESyzpwVE4Imbq85fw50ZHWoDpwDhaekHQDe6kVocinG8tqralCIZELikEvv4/7SjoR21S7XL5DbQ9MIvzJBwzdReHJcWewCbWP9Eo0y4Fg1QNrAletIO34fRfhXd30txa5Ztl05BL3zfxpi8TpLGt4= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2019 04:26:01.9142 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 627982db-3623-46b4-e6b9-08d6a5d9ab7f 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: BL0PR0102MB3585 Archived-At: Subject: Re: [kitten] Review of draft-ietf-kitten-channel-bound-flag-04 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: Mon, 11 Mar 2019 04:26:09 -0000 1. Sam suggested that we consider allowing context establishment in the acceptor-only binding case (i.e. where the acceptor caller provided channel bindings but the initiator caller did not). Sam notes that Moonshot's GSS-EAP implementation allows this, and that policing a legitimate initiator's decision to provide channel bindings isn't security-critical in common scenarios. He nevertheless supports a mechanism to inform the acceptor whether channel bindings were used. I discovered recently that Heimdal's krb5 mechanism permits acceptor-only bindings, if I read the code correctly. So it may be that MIT's krb5 mech is unusual in rejecting the acceptor-only bindings case. (GNU Shishi's GSS krb5 mech does as well.) Relaxing implementations to allow acceptor-only bindings solves the original problem of allowing channel bindings to be introduced at acceptors when not all initiators provide them. But without some kind of signalling, application code can't be certain in advance that it's running against a relaxed implementation. A mechanism attribute is the most robust way to signal this. 2. Nico noted (out of band) that with a relaxed implementation, we can communicate channel binding state very simply: allocate two ret_flags, one for "channel bindings were used" and one for "channel bindings were not used". If you don't get either flag back, you're running against an old implementation (or, on the initiator side, the mechanism protocol doesn't provide confirmation). In this model, we don't need a ret_flags_understood input to accept_sec_context, and therefore don't need gss_create_sec_context(). 3. Martin argues against channel bindings altogether, on the basis that they break proxies and that it's better to use a channel security layer tied to the authentication mechanism. This viewpoint seems out of step with the decision not to provide a security layer in SASL GS2. Practically speaking, the most common underlying secure channel is TLS, whose server authentication (when the client actually performs it) prevents MITM attacks in most cases. It is of some concern that TLS does not have the same server naming or trust roots as the GSS mechanism. I'm not sure that amounts to a pressing need for channel bindings, but I do see some value in them as a defense-in-depth measure when it's not desirable to allow proxies. I don't see much value in endpoint channel bindings. Separately from all of this, I am a bit concerned that we are fulfilling a need to upgrade from no-channel-bindings to channel-bindings, but once an application protocol starts using channel bindings of any type, there is no practical way to upgrade to a different type of channel bindings without application-layer signalling. From nobody Mon Mar 11 11:57:31 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 7AF531311B6 for ; Mon, 11 Mar 2019 11:57:21 -0700 (PDT) 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 UT5gZAi312wo for ; Mon, 11 Mar 2019 11:57:19 -0700 (PDT) Received: from catfish.maple.relay.mailchannels.net (catfish.maple.relay.mailchannels.net [23.83.214.32]) (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 3658E13118F for ; Mon, 11 Mar 2019 11:57:13 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id E5C035C4B41; Mon, 11 Mar 2019 18:57:11 +0000 (UTC) Received: from pdx1-sub0-mail-a24.g.dreamhost.com (unknown [100.96.24.101]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 44FDC5C4707; Mon, 11 Mar 2019 18:57:11 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a24.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.3); Mon, 11 Mar 2019 18:57:11 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Wide-Eyed-Imminent: 591f2a8752cd0a35_1552330631586_2118978103 X-MC-Loop-Signature: 1552330631586:1994553067 X-MC-Ingress-Time: 1552330631585 Received: from pdx1-sub0-mail-a24.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a24.g.dreamhost.com (Postfix) with ESMTP id D72107EF7D; Mon, 11 Mar 2019 11:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=eI45+7J2vADayR wrLwTqbYfdVBk=; b=xQOleXGDcIiyKUYcoN9R0+0QpNR497oMNTnFGFRF4I4E4R z0zbJ1UJhfZxrgdHCASwi5HjBuSjW56O/lcHs7bPFKIHtV4jdzqPB/cD2p+5jzN2 Sp6mPcD7GinZcYY70RJFiMxECvPb9hqtAe7ykYPztYp2bIET6avClIFAsEfe4= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 00E207EF6C; Mon, 11 Mar 2019 11:57:09 -0700 (PDT) Date: Mon, 11 Mar 2019 13:57:07 -0500 X-DH-BACKEND: pdx1-sub0-mail-a24 From: Nico Williams To: Sam Hartman Cc: kitten@ietf.org Message-ID: <20190311185706.GD4211@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedutddrgeeigdduvddvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [kitten] Review of draft-ietf-kitten-channel-bound-flag-04 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: Mon, 11 Mar 2019 18:57:30 -0000 On Mon, Feb 18, 2019 at 04:29:34PM -0500, Sam Hartman wrote: > I've reviewed this document at the request of one of the authors, and > here are my comments: Thanks. > This draft is based on the premis that the GSS-API channel binding > behavior is flawed and that there's a security problem associated with > not knowing if channel bindings are validated. It's only flawed if you'd like to start using CB in applications that lack a negotiation for it. Modifying application protocols is non-trivial. > I've heard this argument over the years, but never been convinced of it, > and unfortunately, this draft is filled with assertions of that fact > without any rationale. In GSS it is generally the case that all features are optional and one finds out what one actually gets by looking at the ret_flags from context establishment, but CB status is not indicated this way. This seems like at least an inconsistency. Perhaps we can rephrase this? > At one level it doesn't matter much. I absolutely agree that a facility > for knowing if channel bindings are validated would be incredibly useful > and would simplify application design. Yes. > However, by jumping to the conclusion that we're fixing a flaw, I think > we approach interoperability and operational aspects with inadequate > thought. I think we discard some of the options too early. > > My past experience is that when we take short cuts like that, we find > ourselves frustrated later when we discover things we overlooked. > > As I write this up, I'm realizing that the draft authors seem to be > making an assumption that there are applications in the wild that pass > in channel bindings to the initiator but not the acceptor or vise > versa. The only such application I'm aware of is gss ftp, which passed > IP address channel bindings into the acceptor and optionally initiator. > It would help me evaluate whether there is a security problem to > understand these applications better. > I note that SASL is not such an application. I believe IWA is such an application... > I think the current draft has several shortcomings: > > * I think that it inaccurately describes what RFC 2743 says and so it > does not call out backward incompatible changes. There should be no backwards-incompatible changes. I am open to re-designing this extension. One alternative way to do what we're trying to do: - add TWO new, mutually-exclusive ret_flags and NO new req_flags GSS_C_CHANNEL_BOUND_FLAG GSS_C_CHANNEL_NOT_BOUND_FLAG - newer GSS implementations will set ONE of those ret_flags when the application provided channel bindings data This is simpler as we then don't need to add a context creation function. Or we could add a GSS_Inquire_context_channel_binding() to indicate CB status. > * I think that it inaccurately describes what current implementations > do. > > * I think that more consideration needs to be given to situations where > one side supports the channel bound flag and the other does not and what > if any signaling changes are required. We might want to extend the Kebreros mechanism to provide signalling about this from the acceptor to the initiator. That could be done in a separate I-D. > * I think it does not consider behavior when mutual authentication is > not requested. In that case the acceptor could not signal CB status to the initiator, not via a context token, though the application still could if it was necessary. > * I'm concerned that in thinking about channel binding we have not given > adequate thought to how channel binding interacts with proxies, reverse > proxies and the like. I'm concerned that this draft makes that > situation worse, and so I'd recommend exploring that at least enough to > understand whether I'm right. As long as we provide a way to discover that CB failed, but continue context establishment, we are making things better, not worse. Presumably the operator of an MITM proxy would not want to permit application-layer cryptographic session protection if the proxy cannot MITM that. (Most of the web is trending towards bearer tokens with no CB (and no proof of possession, by definition), so your concern might not be relevant to the web, but things could change, thus making your concern relevant again. :) > * Please get review from multiple implementors before standardizing the > create_context stuff. In particular, do you want to take inputs like a > credential and/or a flag indicating the context is for initiation or > acceptor. If yo,u've gotten review including from folks like Luke and > they are happy, then this is great. It seems good for API users at > least. Sure. As it happens the authors include maintainers or contributors to two of the most common GSS C implementations. I'll seek Luke's input. Nico -- From nobody Mon Mar 11 13:05:20 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 D3CA6124B16 for ; Mon, 11 Mar 2019 13:05:18 -0700 (PDT) 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 gJQ-PcmjX4rq for ; Mon, 11 Mar 2019 13:05:17 -0700 (PDT) Received: from palegreen.birch.relay.mailchannels.net (palegreen.birch.relay.mailchannels.net [23.83.209.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E9C91200D8 for ; Mon, 11 Mar 2019 13:05:16 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 1E333125427; Mon, 11 Mar 2019 20:05:16 +0000 (UTC) Received: from pdx1-sub0-mail-a29.g.dreamhost.com (unknown [100.96.35.41]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id B4F7B124FBA; Mon, 11 Mar 2019 20:05:15 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a29.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.3); Mon, 11 Mar 2019 20:05:16 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Snatch-Coil: 7d665ebd69ce33ee_1552334715924_1124776506 X-MC-Loop-Signature: 1552334715923:3972237606 X-MC-Ingress-Time: 1552334715919 Received: from pdx1-sub0-mail-a29.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a29.g.dreamhost.com (Postfix) with ESMTP id 546317F1C9; Mon, 11 Mar 2019 13:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=gVFgmwTdFyDu9f EI1YgpEXhw/No=; b=eOiFxJyIUknsK6NZIG64oDM/3TSCSNSPIsu35T8lDSgwuz X2mjmTJWRYa8rxoYRdH6knAVa2hiI3unugNbrk+gbbWdeap0INBEicbnouXFMZxJ GiI9wXhLZ+sbCdXg3Dt4gNs8QR0X7U3NcyrBPaAJqKIBQQ3akhr9G8wdefFz8= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 6DB1B7F1C1; Mon, 11 Mar 2019 13:05:14 -0700 (PDT) Date: Mon, 11 Mar 2019 15:05:12 -0500 X-DH-BACKEND: pdx1-sub0-mail-a29 From: Nico Williams To: Sam Hartman Cc: kitten@ietf.org Message-ID: <20190311200510.GE4211@localhost> References: <20190311185706.GD4211@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190311185706.GD4211@localhost> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedutddrgeeigddufeeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [kitten] Review of draft-ietf-kitten-channel-bound-flag-04 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: Mon, 11 Mar 2019 20:05:19 -0000 How about a much simpler proposal: If the application provided channel bindings, and channel binding succeeded, then the mechanism MUST include GSS_C_CHANNEL_BOUND_FLAG in the ret_flags. If the application did not provide channel bindings, but the peer did, then the mechanism may or may not fail security context establishment, but if it succeeds, it MUST NOT indicate the GSS_C_CHANNEL_BOUND_FLAG ret_flag to either peer. If both peer applications provided channel bindings and channel binding failed, then a mechanism MAY fail to establish a security context, but if it permits the context to establish, then it MUST NOT set GSS_C_CHANNEL_BOUND_FLAG in the ret_flags. That would be the entirety of the normative text. The "MAY" in the third paragraph involves an optional backwards- incompatible change, allowing implementations to choose whether to make it, possibly based on local configuration, or on usage of the non- standard gss_set_cred_option(). Nico -- From nobody Mon Mar 11 13:59:18 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 0BCBB13115C for ; Mon, 11 Mar 2019 13:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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] 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 cu9qzdHK6cNe for ; Mon, 11 Mar 2019 13:59:15 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770097.outbound.protection.outlook.com [40.107.77.97]) (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 F3B761200ED for ; Mon, 11 Mar 2019 13:59:14 -0700 (PDT) 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=bN9PYxWPSRIKOBKTu9yL4Wr1bdVKCSqN8WFwdpjc+zA=; b=elKgr/ydEXDxwh7PMDPyBfAlfvy8cPSmwBm3glJzS4CkRmzs2n3wn68B/59ThdLyiR1XYXXT8U8YyLxqmYGh+SIamBWvfIHeHPm2gzhgxGso3jfe0ENp8q33kSY8qJnjGDyCi/4WnKnC4DVjtOit1dUf4/ZdARjEp4PDsgKhnKA= Received: from MWHPR01CA0048.prod.exchangelabs.com (10.172.172.162) by DM5PR0101MB3178.prod.exchangelabs.com (10.174.181.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.18; Mon, 11 Mar 2019 20:59:13 +0000 Received: from CO1NAM03FT062.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::205) by MWHPR01CA0048.outlook.office365.com (2603:10b6:300:101::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.16 via Frontend Transport; Mon, 11 Mar 2019 20:59:13 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; cryptonector.com; dkim=none (message not signed) header.d=none;cryptonector.com; 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 CO1NAM03FT062.mail.protection.outlook.com (10.152.81.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.19 via Frontend Transport; Mon, 11 Mar 2019 20:59:11 +0000 Received: from [18.101.8.166] (VPN-18-101-8-166.MIT.EDU [18.101.8.166]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x2BKx9nV026867 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Mar 2019 16:59:10 -0400 To: Nico Williams CC: References: <20190311185706.GD4211@localhost> <20190311200510.GE4211@localhost> From: Greg Hudson Openpgp: preference=signencrypt Autocrypt: addr=ghudson@mit.edu; keydata= xsFNBFLMQYIBEADZLNv8Jpeo2d4XSLE+k6m1VD2iOyX66wErZKaQpYrGB/leWKfz8l6c3pWd iVUnCoyxKlhRuGVArszdh2wUSRgHnMl86JC/vIdawdOdbnlTVfOJTiP3EfycsMUUDG6GckLY e+xxo7sM/bpXpGkbIWc0Ec/vbQt67eeW2En1AqL+ezJdVN9XL8icH2Hu6HlqxGgleC5H0yAi kM4yvNjo5z2M/Dr/x63bLcIdKkSRPzd0OaBg2g0Yh651eYpPu0e1Gi6785ZBjV4bnv3K5oLo 5XsiHIZ60maHWTEyMO/byw4aS2cCWIovXurvz699KSF83B296+xhsFhhz4+kbQgXvJt4kIoI pdpX6xbIkeVlc+FuUbyE8MUGveA3TFHXZ4+0f2tvTekey/62FOeXnrqc4NsBViir3zGTXAqC 7PQTNnX/86jyW+9SnJo9XbSBB3NV0K5I2o1cDzqRPqy/4fsoq8SxQwRga0CSId1PzE9PUEUY V0FCldo9LvPsUK9YE7AuwC+bcQiVLah5TF+5Kk7yLSaRxzQ3fI5lcqk5UPUqMLa87cRBdnal niuHVg0u3W22RMPkWe2iPIYYdr4TQDzCkD2JXpXNaZ3KipVT5aqowwfPEt7b6ti0vjrOInij YzFmVNMGKYabwh2zxKWQQ8GO5mUVu09CSe33H4EW7pDP+zHr2wARAQABzR1HcmVnIEh1ZHNv biA8Z2h1ZHNvbkBtaXQuZWR1PsLBeAQTAQIAIgUCUsxBggIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AACgkQDLoIV1+Dct8dZBAA1Mtoq1RPuUQg6hL2qFjwTEXeonWq8czkQ1fNNzO9 x8I3VLn5L6CmWeAmxRU1DD0qZ5HL24+Mwnvy/eazp4/CSgiPC52KfbNsnQtg/E+8ruFQVHA/ 3HZXuCT/Nz4s06N3fMZrJLCGNEHRD0S43kb2GGboVY3ykO3FbPJB/DxDqtIMqt6B1SZ87UAR CVsRc296X3TsF9BgoQ/n54XfYAzrACkuIH9biHmH6wB1eykCeuhkCsu5Zf/tlSXJCFiuhvS+ CX2EbNKF+0MLcGAavSzbjTnQw3kv8unSgecbEQ7A8ibGx6Jwgnvy0gzu6w4prhR40pVYDcL+ sKsmQg6jo/uPvGdEqHISFSK8FxGGAonaAwg0014bXLaPo2MckcZ+szcHA/z4vpTdB1vChexL omM5ZTeSJaFfeYsspv8sq6EL1x21c7A+ngCmB70/OZR6dcgf9/ILmcjBiYfJHYukXTIvGT6y QJbok19So8RJKUYjzzHDKBweg8x6HdIrdy7HTcLzsqY9PFGg7/YlbLlGQwYXhK1b4uBmWyE7 I/402+57I1YpMYND7vsTmJuE13Gv5ZGhYn5pSzX9ZTWY13LgGymkWBXPxfefkHKTV9ROCGEL t7SV3Nf7ZsCGLRGmDT6oqLz75/IrhKEcHIfD4ct+QvIm6pvPNvikQMwPWSd52GazILLOwU0E UsxBggEQAKaz/wX8nsSUaivmwW4NVlbmTsErHUt9iNHm9CmieuoDv1o8qUqEV6RiONIs0q5Y +dcooazhHRNpjAST2rbQFBZebfpVRKYAGzHoZEQ6OV8Eao+NjAGazS8RuwIxpeZ36r3AyVhe TAIvIzwpQFDNKTIUNbXctHrZ157TlxDuKwZ3+Yw/bhQE5YGrSLm17wIMcY3UHiE1mO5X0ohR dDeTf93PignUUvWvRRQLyxRGsBLz/CCwmCJZeu/FjnDk8HkEbAlmFAJ+YZu9rQ40vU6Z40KY L5U9PIn0FdSxviK7mys+VbFYV6mXWXZN8dOkHuG6zSdmobE90G6ZzAPcI4cyql63N+kUOb3b hGI/Wvn6tUbWeIc8UvQGpYb0+eOKHQBNKUOq5RV98hZorZRCu2W2RzZSxiufyONvtonbUtYs BMdw+gqUpK0ir782lc3cKbj+X5iiyg3ZGvBmTU6FN/MiX6MnTyEwOScFboKe6vB8ZgwII85K n9qlSI3xH56JBXamMP0yqJf57q0WfP8V7lFtm8SmhU2NQyP3wRYDm2+bLTNCmRPJN2ZUgkTx c/Qjov8TeeiTfX9S3ea/GJOdgA1mQfSkmUoOWROnwDBbKGBXNzkkoJna8j/zWgo/mQ5gNdIu HXcIdDKbyyhVH3+DwxXYWyYP/pnIk3AVCss75dXcdStfABEBAAHCwV8EGAECAAkFAlLMQYIC GwwACgkQDLoIV1+Dct+oSA/9HyTkr+UQbaucXE9pP87yasObKCBxYhoeRjzBhgtYUtSDuH2o xl5M3wmTNOooQSa8R1ljhax9v02pqspIA9hyGjGjvZ6jPydDsANNcohdbMjCzXNdrCF5149w gbGQ07rkc5JNyajzxH4GE/BXclTzwTYAaHvYM5PEQLDhmubK3M/kBvjWpZxLAJAobMi/jVwQ cmai+N56X9Ht/FVIQlmCuXoMAE9ScVWFaq8JnCo9VZ0G045NcxdEoQXVUXb3E5cmZ0Ld9sUm SKSJKjYWjfE4c/8oylZuo9LDTwozBEp/jsASjL0g8F3QJsQUkFkKROd45xHcIkFulshS3xkG gMu6UduV2ypPz987f+0wdVwx+KYnmnUB83gxqVucFRxfZZXiUHUml4rJ7Ww2+//H9FFPfw9f aPMg7nLFm2T0to3pwgyisLH/aThzW3TY7CZ7gkvMDtbo9EHrN4Nl3onuOtOKQpIMbFVqX4YZ m6znSLuUiWDUd8rvQfz+4ndZKIFOG1YIKwQBV8tN1RYBGY9bhv2Wtt5X6SKIzkUhDdgeyzci MC1M3N0Pqoqrms7FdBKAd0BE7puhQ24U42APss+Ur6WyRZMQTKc41SZWfrWV30agytUVdtRu gxERw74qeGAz6o3if42vI6u30SR6OCLMMSobqKc7HQvJ2qv3Z6j9kt1zXiE= Message-ID: <2a5b3df4-f728-bc6b-b504-10ff19536521@mit.edu> Date: Mon, 11 Mar 2019 16:59:09 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20190311200510.GE4211@localhost> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit 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)(39860400002)(136003)(376002)(2980300002)(189003)(199004)(6706004)(23676004)(6916009)(47776003)(14444005)(106002)(104016004)(65956001)(356004)(50466002)(11346002)(65806001)(64126003)(229853002)(786003)(53546011)(58126008)(486006)(6246003)(65826007)(2616005)(88552002)(26005)(31686004)(476003)(4326008)(186003)(36906005)(316002)(106466001)(5660300002)(305945005)(2906002)(246002)(126002)(8936002)(26826003)(230700001)(478600001)(956004)(426003)(7696005)(31696002)(2486003)(336012)(76176011)(36756003)(75432002)(446003)(86362001)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR0101MB3178; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c84d74f4-0c1b-4479-b775-08d6a66469bf X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:DM5PR0101MB3178; X-MS-TrafficTypeDiagnostic: DM5PR0101MB3178: X-LD-Processed: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; DM5PR0101MB3178; 20:oSM/7267cEuY0rDEBb4wNQfKcD9Xs6ssD1x7TcVlP5u7kyHinR8ke/gucCx781f2f8LULF269W2AN7qmtbfDcXyWGYhB87muUptNBAHVA79jfOYI/RoQP8ZKp0Z0DcSCsqgGMxtGJQvzJ58oxewXoC1mszq8e0DSVKykHxLUjsHKf4nvz+rcARzggV881TKpz0h2xsubNjfPBdwHcSeIuIowm+70S95fjRbegt1BSU1ZsIwzJzu+cppozhAt9aJm56GWhWaiEFcrAr65zCHYuD7puwtiiI1f7znjTa1wVVgot5mp+oxAX5YB1qCGvJaQRgXqGY4TvyeY1+SD5t8dvIaO7IUr9ulRFA1SYAw+MD+CO7X6+3GwzuWe9lUz8byLmCnWCYzg28Tufgmaw5OXCip0Im99iOrfj1jTtMt5nonviyMRn81Qq+XWfRHhT2VhUC+4KN/YpewXyMZXDxZ1jk2GeCS85NAsHGGtKjHJYIxdrg9wVb5vwi7UCUIfcviuX0LgrOTw/oGJ2aCrKPOyKaDOi0WyUhC8IV9Qx/PHcFehs5YA3oOLUycBCBpbVbwx/ZaEbOllZqQzzc0CPsaV+Ud/97W20oYNU3kfQw8UiQk= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 09730BD177 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTVQUjAxMDFNQjMxNzg7MjM6SFpabkVucGk3L2JNSGJaSmpMRHV3RklQ?= =?utf-8?B?UEtHVHVCNG9NdnlXK1U3d0lCWGZWc25VM1cvNGtkbkw2YW1mMHlVekR3di9y?= =?utf-8?B?RGhmUHNIazRnY3Z6Z29DQzU4RHlNREpPdjdENUNlYU8xV01oU2NmVXFjOGVL?= =?utf-8?B?WEg2Qkc1bExyYnlVNkRCRWh0UjZnSzBrRFNaV0RCYUNVdlFwUjFtZk9uNGFx?= =?utf-8?B?aXE5d2MwRTlyRzRUa1RpU21PKzQxSXQ5WmFDZlhhVHZQbUJGckdEZWVjUklW?= =?utf-8?B?RElZMHluWVp1bDhmRDk5YzdKMnpQQWFqQWRpcmN6QnZjSWhtSzJ5S0pHL2wr?= =?utf-8?B?TXAxWEtYUXlYOC9BUHRjUmpreFRnRVRRR09kMzJxQkcyS1BSZGJwRXFsMmtC?= =?utf-8?B?TFdPM2FDWlNvN3h4N25zN1hZTXBObW9wWVpibEJaeW52Q0N6ZkV0N2RXME93?= =?utf-8?B?Q2lUaGJiUkoyLzk4YWdvbmhURUhVVXpoaTZGS1RJdWZVUzY3OGtkVkVLdGVa?= =?utf-8?B?REZHeW5XRHZwWkIvb25TMTRHWENYZTRJbGMrZzg4Q3VUM05PUktkOTE1dk5W?= =?utf-8?B?KzZRYnFQcVBYT1Y5bDZpYTV0RnV6VCtVSDFxeXYxY085S3dNT2RHVEJySnhY?= =?utf-8?B?dE1xNDRiZ2wrd3dRdG5RVU5BMWM5NHAzdWlLZXREZU15bm4zaUlQNzlYb0Mw?= =?utf-8?B?dW9RV3NiMEJKS3lMYU9xYjA2eXZianJKOTB1Z280Z1RCUnhUR0YxVE45S2pX?= =?utf-8?B?bXhFamhBTy9sa3RVaVlxMytIMk1hWWVEQkN3MWNpbDFmeXRNVHdoZU1qUmpF?= =?utf-8?B?c005WEdyeCtKWFlZT1FBU0tiekJUOVFHNWErSHFvZjZZR2VsQjBhSm4xK2Z4?= =?utf-8?B?NVVQais4WmFNNWJlWE03SVBoZnN0VE1xMXJuSDFxV0RTRHFwd1lka3k1d3VT?= =?utf-8?B?WFliT2p0VmUvZUNBM2ErSDZqK0E2c25zQzQ2VExFUEttcm5HZUdOSkMwTXR6?= =?utf-8?B?bFg4T0ROVHBUemIxVUk0NVp3TzB3Vmh2YlVQdFltQ3NremlwdmZpU25VZFl0?= =?utf-8?B?OGxXUkppNUJZZU8vb2U2b2hnbEFXVklJVVA1aHhWMVpIV0RUUVJRbnlUMkdr?= =?utf-8?B?WFlBczV0R3BNNFRTd0Faa0lqWWM1RVNucUt6S2ljclU1clRaanl5YWcybVYv?= =?utf-8?B?c2xwb3dNVnVKWjlKM3h5QWx5ZCtVaFZ0c2FjS3hzN1NIVlBNQWlzOFRxM3Jo?= =?utf-8?B?N293ZVRmUGQ4N2VIYWdkQk9idm5SSkxnQWJRakhrS3ozV3VITlBrek5vYjY4?= =?utf-8?B?TEorZXQ1ekxFZmRXOEovL2cxbG1DNjRNc2tQdmlxRnYxVkhiZjZZVXRBYUhZ?= =?utf-8?B?azhXV3dqdlVMTDAxWkJGSWFJRUFLT21ZYjh2Y0xKTFVjN0FNRTA5TDl2ZFgv?= =?utf-8?B?UTNBUGxSbFB2N1lTbzVSY05mL09ZbHA4Z09QZXZCMWVLMUd1U2hnNGo1em9S?= =?utf-8?B?bjRKd2NlcXJUdTdUT293c05tUXRENlFBZkZtWkhnNmh6cU01dWdJeUcwaHJn?= =?utf-8?B?SDJiYkpmclhOM2YrM29VU2s4dW40anc2V1JwUjUvZkx2dGthczVFY2h4Szhp?= =?utf-8?B?c09BT3BTN1V1dW1hN0RTaktKYUUxRXgxN3BydEVUWTBvcFZWVE12dnJPMXhK?= =?utf-8?B?MHNsTDlnbk44anZTalFzdm1lYnlYc2VsSUNRSXpXTi9qUWtvbEFWL1FjSm1a?= =?utf-8?B?bEltTE9yTDFzNTRUelBoc3p3PT0=?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: iuer0V6iQDkFAxicHWd7U1hPWTV4yn9i3UqkRp4InYp9ilvrWfBbatYbkYF1e6wB6m+7++DKXtBoZSV06dUumSxysQaxTF2ff3K8+4BjZwQ30pBtRmhmxshpc6t62dpWsblvaS88gaHMycSG7wdjCwWz6lbhJiv+fcFAkvKhl2AhWuyhN2j2BnzWOZB9Xnth095R7YtdzQiR9U8sUI0Ad+gBTbuO9DQ8w7tffz/XajspHPmAxDjn6J2ZM7makhoh2n5IKvmdvax+nQM/rIWB5DCltuhYPMHOTM/9Cu7u/vHcc2KimCekfCoARRV6SDohtNxg+Yrijk7gPquDpUxtFwuYVQVGA6evI2A0nLlYe/8q0NiyIrrI9ltogUKfmFi6Falk9WSSCzwQin4yyEpvegl9eou+V2ab4yc0qami9pg= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2019 20:59:11.6477 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c84d74f4-0c1b-4479-b775-08d6a66469bf 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: DM5PR0101MB3178 Archived-At: Subject: Re: [kitten] Review of draft-ietf-kitten-channel-bound-flag-04 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: Mon, 11 Mar 2019 20:59:17 -0000 On 3/11/19 4:05 PM, Nico Williams wrote: > If the application provided channel bindings, and channel binding > succeeded, then the mechanism MUST include GSS_C_CHANNEL_BOUND_FLAG > in the ret_flags. MUST for accept_sec_context and MAY for init_sec_context, I assume. (Since existing mech protocols don't provide CB confirmation, and CB confirmation is typically impossible when mutual auth isn't used.) > If the application did not provide channel bindings, but the peer > did, then the mechanism may or may not fail security context > establishment, but if it succeeds, it MUST NOT indicate the > GSS_C_CHANNEL_BOUND_FLAG ret_flag to either peer. > > If both peer applications provided channel bindings and channel > binding failed, then a mechanism MAY fail to establish a security > context, but if it permits the context to establish, then it MUST NOT > set GSS_C_CHANNEL_BOUND_FLAG in the ret_flags. My first concern is that this provides no meaningful promises to the application about how accept_sec_context() will be affected by channel bindings. It might or might not cause failure on mismatched bindings and it might or might not cause failure if the initiator provides no bindings. We could add mechanism attributes to distinguish, but that unfortunately only helps if the acceptor is limited to one or a few mechs (none of which is SPNEGO), since the choice to supply bindings comes before we know the mechanism of the initiator token. My second concern is that if an acceptor application does not see the channel-bound ret_flag, it cannot distinguish between mismatched bindings, a lack of bindings from the initiator, or an old implementation. (Knowledge of the mech implementation might rule out some of those possibilities.) If the goal is to allow applications, whose protocols can optionally use gss_wrap(), to save some CPU cycles when channel bindings succeed, this might be good enough--though in many cases admins would have to decide whether to supply channel bindings based on knowledge they shouldn't need to have. I'm not sure if this is a worthwhile goal--do we know of any specific applications which would benefit? If the goal is to achieve defense-in-depth against MITM attacks when TLS security fails, for protocols which never use gss_wrap() and at the cost of disallowing proxies, then these semantics don't seem likely to achieve the goal. From nobody Wed Mar 13 12:14:56 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 21F42130EF7; Wed, 13 Mar 2019 12:14:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christer Holmberg via Datatracker To: Cc: kitten@ietf.org, ietf@ietf.org, draft-ietf-kitten-pkinit-alg-agility.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Christer Holmberg Message-ID: <155250448007.24976.5936301058492712585@ietfa.amsl.com> Date: Wed, 13 Mar 2019 12:14:40 -0700 Archived-At: Subject: [kitten] Genart telechat review of draft-ietf-kitten-pkinit-alg-agility-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, 13 Mar 2019 19:14:40 -0000 Reviewer: Christer Holmberg Review result: Ready 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-pkinit-alg-agility-06 Reviewer: Christer Holmberg Review Date: 2019-03-13 IETF LC End Date: 2019-02-17 IESG Telechat date: 2019-03-14 Summary: The issues I raised on the -05 version have been addressed, and the document is now ready for publication. Major issues: None Minor issues: None Nits/editorial comments: None From nobody Wed Mar 13 12:29:51 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 06235130F34; Wed, 13 Mar 2019 12:29:35 -0700 (PDT) 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 (2048-bit key) header.d=cooperw.in header.b=VYfmV7r7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=y1s7EbNL 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 N3rNbFDtAvAn; Wed, 13 Mar 2019 12:29:32 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97D48130F30; Wed, 13 Mar 2019 12:29:32 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id EB70422045; Wed, 13 Mar 2019 15:29:31 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 13 Mar 2019 15:29:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=7 StOm2JxC73HdtMynir47u+zts+HpMVg5VlAHkezJDk=; b=VYfmV7r7F8L+PBJtf /mZ4qvKVJ0Ll/gcy8/9Pm8H3yCh1C4UOjlh/DJPv4yzu52VhC1VinB8WoBTxtCC0 LEt8dleab2B4SzDdysZrsAkn2cIM7cAS6YzBIujvMElHrjdAvLtSXyuuv0B77/uD wl58HQz/96dTIddXXo+y306VsIf0g0H6oVxCAECvCdqfXwyeis47YRTqkG2CT3Gj ZgB57RxXclKlZSfa/xyko4b/EQ61NlVa6tLdsupYE+jkpdk+cIgGx30eseBSGg3d V1rBad2BmvwQShf9uATJIj+FUNwwj21uXAoNYy1HfrErXaHAYETlkijRSWkXEA47 OasuA== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=7StOm2JxC73HdtMynir47u+zts+HpMVg5VlAHkezJ Dk=; b=y1s7EbNLx+95iGyZ1as8PudgV2UBZiEiGj5BWN/swxVjz2PxLioqQ7d6R 1Mo5uY8xkmsf8uMXJBtu7jJtKgQZDVNwXSUKKG7ufJdCrgLJ3fJy08RzVwPEvJ/N 1E87F9rQ5S/Li6DA6x680WHX1CcBEy+hSvetaBMAp2xz6CNdreOkAM2rb/gjRMAv 7Q71QVk9eiTs0nDf/PV1fwOlf4Y3PskPtGUtxE7yqNnZYQhf8BF3TO0/0+0tVfd8 UpwqJjIaeWwEe9HzuxsSEA5NzcT3jb241xJLqT7rZuLrkEdzKy9V8ttjzKpKe7cH LLqRIp2Dmc7JrlgMQDNAwDZcXv7gg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrhedtgdduvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrieehnecurfgrrhgr mhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsth gvrhfuihiivgeptd X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.65]) by mail.messagingengine.com (Postfix) with ESMTPA id 0C9BAE4240; Wed, 13 Mar 2019 15:29:31 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <155250448007.24976.5936301058492712585@ietfa.amsl.com> Date: Wed, 13 Mar 2019 15:29:29 -0400 Cc: General Area Review Team , kitten@ietf.org, ietf@ietf.org, draft-ietf-kitten-pkinit-alg-agility.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <155250448007.24976.5936301058492712585@ietfa.amsl.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [kitten] [Gen-art] Genart telechat review of draft-ietf-kitten-pkinit-alg-agility-06 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, 13 Mar 2019 19:29:35 -0000 Thanks for your review, Christer. I had entered a No Objection ballot = when this document was scheduled for a previous telechat. Alissa > On Mar 13, 2019, at 3:14 PM, Christer Holmberg via Datatracker = wrote: >=20 > Reviewer: Christer Holmberg > Review result: Ready >=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-pkinit-alg-agility-06 > Reviewer: Christer Holmberg > Review Date: 2019-03-13 > IETF LC End Date: 2019-02-17 > IESG Telechat date: 2019-03-14 >=20 > Summary: The issues I raised on the -05 version have been addressed, = and the > document is now ready for publication. >=20 > Major issues: None >=20 > Minor issues: None >=20 > Nits/editorial comments: None >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Mar 13 13:05:06 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 9132C1310CB for ; Wed, 13 Mar 2019 13:05:04 -0700 (PDT) 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 3Uh_PKXQ9XIW for ; Wed, 13 Mar 2019 13:05:03 -0700 (PDT) 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 E83FA13104B for ; Wed, 13 Mar 2019 13:05:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.suchdamage.org (Postfix) with ESMTP id F26702D640; Wed, 13 Mar 2019 16:05:01 -0400 (EDT) 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 k6Vk8Oy9itrC; Wed, 13 Mar 2019 16:05:01 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-24-91-242-186.hsd1.ma.comcast.net [24.91.242.186]) (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; Wed, 13 Mar 2019 16:05:01 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9D344C07D7; Wed, 13 Mar 2019 16:04:31 -0400 (EDT) From: Sam Hartman To: Nico Williams Cc: Sam Hartman , kitten@ietf.org References: <20190311185706.GD4211@localhost> Date: Wed, 13 Mar 2019 16:04:31 -0400 In-Reply-To: <20190311185706.GD4211@localhost> (Nico Williams's message of "Mon, 11 Mar 2019 13:57:07 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [kitten] Review of draft-ietf-kitten-channel-bound-flag-04 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, 13 Mar 2019 20:05:05 -0000 >>>>> "Nico" == Nico Williams writes: >> This draft is based on the premis that the GSS-API channel >> binding behavior is flawed and that there's a security problem >> associated with not knowing if channel bindings are validated. Nico> It's only flawed if you'd like to start using CB in Nico> applications that lack a negotiation for it. Modifying Nico> application protocols is non-trivial. How about. "GSS-APi does not provide a mechanism to add channel bindings to applications without adding a negotiation mechanism to determine when channel bindings can be relied on. This draft adds such a mechanism? " I'd avoid the word flaw in such a case, but don't care that much about the text. What I do care about is that I now understand what you're trying to do, and I'm really happy about that. I support the goal, with some caviats I'll discuss below. >> However, by jumping to the conclusion that we're fixing a flaw, I >> think we approach interoperability and operational aspects with >> inadequate thought. I think we discard some of the options too >> early. >> As I write this up, I'm realizing that the draft authors seem to >> be making an assumption that there are applications in the wild >> that pass in channel bindings to the initiator but not the >> acceptor or vise versa. The only such application I'm aware of >> is gss ftp, which passed IP address channel bindings into the >> acceptor and optionally initiator. It would help me evaluate >> whether there is a security problem to understand these >> applications better. I note that SASL is not such an >> application. Nico> I believe IWA is such an application... I'm not familiar with that application. Pointer? >> I think the current draft has several shortcomings: >> >> * I think that it inaccurately describes what RFC 2743 says and >> so it does not call out backward incompatible changes. Nico> There should be no backwards-incompatible changes. I listed one later in my review. In particular, RFC 2743 permits a mechanism to entirely ignore CB. This draft requires that if an initiator passes in channel bindings without the new flag, then CB fails. I think that is not required by RFC 2743. As such, this makes legal mechanisms under 2743 into non-compliant mechanisms and thus is a backward compatible change. Nico> I am open to re-designing this extension. >> * I think that more consideration needs to be given to situations >> where one side supports the channel bound flag and the other does >> not and what if any signaling changes are required. Nico> We might want to extend the Kebreros mechanism to provide Nico> signalling about this from the acceptor to the initiator. Nico> That could be done in a separate I-D. When I read the current draft it's not clear to me which sides get the flag set and who knows CB has succeeded. One advantage to adding Kerberos signaling here or in a normative dependency is that we could give both sides of the conversation info about whether CB has succeeded. I think the current draft is too silent on whether the initiator learns about CB success, the acceptor or both. And unless we mandate signaling, I think who learns about CB success depends a lot on the mechanism involved. I'd like to walk through what guarantees we can make, and then make sure that is actually what applications need. >> * I think it does not consider behavior when mutual >> authentication is not requested. Nico> In that case the acceptor could not signal CB status to the Nico> initiator, not via a context token, though the application Nico> still could if it was necessary. First, you seem to be assuming that it's the acceptor that verifies CB. Is that actually guaranteed by GSS? Second, how does the acceptor application signal to the initiator about CB? The channel might not be verified, so the initiator cannot depend on that. There's no mutual authentication, so it's not like the initiator can know that a wrap token is from the acceptor. I actually think CB may be kind of useless without mutual auth. My point is not that the draft is broken, simply that it doesn't cover the case, and I think application designers are unlikely to be sure on their own. >> * I'm concerned that in thinking about channel binding we have >> not given adequate thought to how channel binding interacts with >> proxies, reverse proxies and the like. I'm concerned that this >> draft makes that situation worse, and so I'd recommend exploring >> that at least enough to understand whether I'm right. Nico> As long as we provide a way to discover that CB failed, but Nico> continue context establishment, we are making things better, Nico> not worse. To be concrete, I'm concerned that this makes channel binding better enough to work with proxies, but doesn't provide us channel binding type agility. Addressing my concern might look like talking about proxies in the security considerations section, noting that things like endpoint channel bindings are easier than unique when you have proxies. And then noting that we have no plan for what happens when an application without cb negotiation needs to change the preferred channel binding type. >> * Please get review from multiple implementors before >> standardizing the create_context stuff. [This point has been addressed; Luke seemed fine when he wrote to the WG] From nobody Wed Mar 13 20:40:13 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 0627013127F; Wed, 13 Mar 2019 20:40:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla via Datatracker To: "The IESG" Cc: draft-ietf-kitten-pkinit-alg-agility@ietf.org, Robbie Harwood , kitten-chairs@ietf.org, rharwood@redhat.com, kitten@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Eric Rescorla Message-ID: <155253481198.24861.15849658500473174931.idtracker@ietfa.amsl.com> Date: Wed, 13 Mar 2019 20:40:11 -0700 Archived-At: Subject: [kitten] Eric Rescorla's No Objection on draft-ietf-kitten-pkinit-alg-agility-06: (with COMMENT) 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: Thu, 14 Mar 2019 03:40:12 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-kitten-pkinit-alg-agility-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-pkinit-alg-agility/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- IMPORTANT I think this document would benefit greatly from describing the downgrade properties of each of the axes on which algorithms can be negotiated against various forms of compromise in the digest function. The relevant case is one in which the client and KDC both support one weak and one strong algorithm. Can the attacker either (1) force them to complete a handshake with a weak algorithm or (2) convince one side that the other side supports a weak algorithm and then interpose itself as that side. Specifically it would be useful to know which attacks are possible with a collision attack versus a preimage attack (though this can sometimes be hard to know). Here is one case of a potential real downgrade attack (though not a very powerful one). The client sends a KRB-REQ signed with algorithm A, the attacker forges KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED listing anly some weaker algorithm. This causes the client to retry with that weaker algorithm. Is this attack detectable? It's not clear to me how (though it maybe could be if the message were folded into the transcript). OTOH, I don't think that the equivalent attack on the cert signer algorithms is necessarily very useful because presumably the certs are public already. OTOH, it might force the client into using some weaker key. I'm having a little trouble following the point in S 3. Is the idea that the paChecksum is always SHA-1 and you don't add a way to negotiate it, so you are instead folding the information into the KDF? If so, I think we need to work through the chain of logic here. As I understand it, the paRequest is included in the AuthPack, which is signed. So presumably the idea is that the AuthPack is signed with SHA-256 but because paChecksum is SHA-1, the binding is weak, right? But can you safely send a SHA-256 signature to a KDC which you have never talked to before? Can't you just get downgraded by the attack I describe above? Can you help unpack this for me? MINOR I wish you were using HKDF, but I don't think this is a dealbreaker. From nobody Mon Mar 25 09:35:46 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 0E026120412; Mon, 25 Mar 2019 09:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 lcU9ztxBg46w; Mon, 25 Mar 2019 09:35:43 -0700 (PDT) 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 A10921203FF; Mon, 25 Mar 2019 09:35:43 -0700 (PDT) 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 EE1B8309265D; Mon, 25 Mar 2019 16:35:37 +0000 (UTC) Received: from localhost (ovpn-112-38.rdu2.redhat.com [10.10.112.38]) by smtp.corp.redhat.com (Postfix) with ESMTP id B246A5F9CD; Mon, 25 Mar 2019 16:35:36 +0000 (UTC) From: Robbie Harwood To: saag@ietf.org Cc: kitten@ietf.org Date: Mon, 25 Mar 2019 12:35:34 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" 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.43]); Mon, 25 Mar 2019 16:35:43 +0000 (UTC) Archived-At: Subject: [kitten] Kitten WG report 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: Mon, 25 Mar 2019 16:35:45 -0000 --=-=-= Content-Type: text/plain kitten did not meet. The working group addressed changes from review to pkinit-agility, and the document was approved for publication by the IESG. Shepherd review for SPAKE was completed, and we advanced that document to the IESG. Currently, we are working on redesigns to channel-bound-flag, and also looking for new work to take on. Thanks, --Robbie --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAlyZA1YACgkQJTL5F2qV pEL4jA//W/f6GZ8ZIPoivIvJ+UHco8k10vhx+XUJCdjgcyS8MZR4xEWVknkO+61O 5dlQtyfTu0AMlqMnll2LJjfNLSIVSb+3nrzJQo5fgUNF66TZYkCKwp9ZPN4FwCwm yzdZZor8bov+mn4NIb6/nspRa0LvTAKvSmBSB7kyg5Mm9GtJOM6HRqGwJrWQj0SE OSv50FzWzY+0LmX8WO73CxvC3+oqtE5HOtQ8bgBGJagAd2sZqpjP/sb6/1qxZAkR hOD0b78wyAVcKmoRfhfDi4/EkT7xe86Jun7WqbGCrzw6ONB93DM7/jO5tV0QEc/n YJLTnfj6DVgLQhEBmBP376v1V6ISs70+DKYtZIpa1EGMMRyBKbDt0ZnUlb/9tu9a xulwQb+cor/S0XtMUL/Hl82YWxMrcVl63cJPad+Zeut+3dG0jEvbdMuEIA9TjqRp nEqr9crATrcCHDpGHPH4r39km7UjZDHyEfLOAIlu/TENH/ToOgZIG1yk5UqKbFbq nDjkLQQl6YSy8SCXQXnk94Pefwy7dKJcln8bNhQcPbiz9YLKIMljW8IFPEGJFY86 LF5TSCP8YLB8ul/ZuxunGRpkpJ1LiQBNWUHgTckwCPyIEORPx9l4iw93WuE++xpM HcqO/hhjhhseH6/Yb1JlZ2XLWdfFGCBuPKziTcj/jJzbN1t5sLw= =r9Xt -----END PGP SIGNATURE----- --=-=-=--