From nobody Sun Feb 3 08:37:52 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 598EB12008F; Sun, 3 Feb 2019 08:37:44 -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.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: kitten@ietf.org Message-ID: <154921186431.11029.11064064648648781357@ietfa.amsl.com> Date: Sun, 03 Feb 2019 08:37:44 -0800 Archived-At: Subject: [kitten] I-D Action: draft-ietf-kitten-pkinit-alg-agility-04.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: Sun, 03 Feb 2019 16:37:45 -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-04.txt Pages : 19 Date : 2019-02-03 Abstract: This document updates PKINIT, as defined in RFC 4556, 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-kitten-pkinit-alg-agility-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-pkinit-alg-agility-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Feb 3 08:53:04 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 4363E127598; Sun, 3 Feb 2019 08:53:03 -0800 (PST) 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 8xot1prcD0tx; Sun, 3 Feb 2019 08:53:00 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740123.outbound.protection.outlook.com [40.107.74.123]) (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 DFB8412008F; Sun, 3 Feb 2019 08:52:59 -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=iLGtEqb8jW5D1SvTA8VnRvIoGoH0yWn3hzia82PFU/0=; b=U5u9HsWZIb/ETKAdUhj3Z83vRMDn+K82yMEcoFk1sJFikLuUz9CN8GhCZk0OMX1cldlCAb52YiljV/bzrJa7EPokemXQ1nk314hRFY3EH8pCUStQ0zqAClaCKwg53FUk/qC1wsciDuM56rVMcSIm/Y5IiynW+Mvz4DsZr0vC2zA= Received: from SN6PR0102CA0031.prod.exchangelabs.com (2603:10b6:805:1::44) by DM6PR01MB4490.prod.exchangelabs.com (2603:10b6:5:78::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.22; Sun, 3 Feb 2019 16:52:57 +0000 Received: from CO1NAM03FT057.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::202) by SN6PR0102CA0031.outlook.office365.com (2603:10b6:805:1::44) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.17 via Frontend Transport; Sun, 3 Feb 2019 16:52:57 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; mit.edu; dkim=none (message not signed) header.d=none;mit.edu; 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 CO1NAM03FT057.mail.protection.outlook.com (10.152.81.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.10 via Frontend Transport; Sun, 3 Feb 2019 16:52:56 +0000 Received: from [18.101.8.123] (VPN-18-101-8-123.MIT.EDU [18.101.8.123]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x13GqsVS024492 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 3 Feb 2019 11:52:55 -0500 To: Benjamin Kaduk , CC: References: <20190130224555.GE49072@kduck.mit.edu> <20190130224805.GF49072@kduck.mit.edu> 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: <04550c84-f6e4-7799-195d-dff3f504ee33@mit.edu> Date: Sun, 3 Feb 2019 11:52:54 -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: <20190130224805.GF49072@kduck.mit.edu> 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)(376002)(396003)(346002)(39860400002)(136003)(2980300002)(189003)(199004)(478600001)(65826007)(104016004)(316002)(6706004)(786003)(36906005)(26826003)(47776003)(65806001)(230700001)(2906002)(65956001)(356004)(88552002)(106466001)(7696005)(2486003)(23676004)(106002)(76176011)(31696002)(86362001)(50466002)(336012)(6246003)(486006)(126002)(476003)(64126003)(2616005)(956004)(4326008)(2171002)(450100002)(8936002)(58126008)(110136005)(305945005)(26005)(229853002)(246002)(426003)(186003)(14444005)(36756003)(31686004)(11346002)(75432002)(8676002)(446003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR01MB4490; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM03FT057; 1:xB2Z4SbQnl4/fEgH/VZ5Q58eb3cCEPheifVVLmu3Exac1k8AiyjvWyvt8v7Fm3y4ZshXseHGBU3VEL6saJPF9+ZzUOrrId+ACgrp1UPdUukFwv15cF9A9Wj5ZGjRtLWyrvLHrCsh3J/58W4X5Clzt9fI3dQbeYNhx/hxXbDdOsI= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6a0fc7d7-ea9a-4593-d574-08d689f80c3d X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060); SRVR:DM6PR01MB4490; X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4490; 3:ImwWofF0WP+tTdYloIVZ9LWkSkZaKcAs9WbFUZDNqU8ysRQcuAUrQtWdcxfj3O0Pix+0f00LAGVqGSEx4k9sZBlqrCyEHoPrn7rmw0QqbC8ogqx4JWVUEni1sfkZsJMD4fBofMGrxYNbVHv6tMGxScIsZbOAGi+jT5Y3nuleQT+qqkV/OCzQKr0aM3Kw5/5sK6H/199DKUn/tiWJWBtqcSWmv4PDxIWnpuj8zU4hfI4Jvnt1Yyw/e21U+gxTWWlUEWXAIulHL61RXJecB7huyhaQ1zsAowPZxrmh4mElPth5uLvbw069ghOXMHXua8X56+FbUui7G4xP6XRjBSHhqYZTjtxIxZnCMHlLiu9sEqMCPyA2DCnCaiaDgYheWAdK; 25:CULjdFIrgwt37UFnpr7Q2BB2TCwicjZrvEOThJMluP6rAhM3Fs65sv2sarfW+hVkku0Dq/ZCwn+RcAWnHd/waxijOk9urcGD8/r+iiay/FuYrgnDPGwediG40ishrNkAoKAT/aNZi1ucc8dY3W5ZyUus8Xqm3c3ILVItv2PM0xkfgskgQrzN8I+ZvKp0H7r49Unl9/2IdJC1gePl1LvXiYD7bRMlNJVWrpQji2mMpU34mtTn8TQpVH2Pp4pzB5wC1Wy3vHcbBn1nV9vdEN5zk/0Z6KIj1/73ct6Hr+onbaqeyMguLrsbWUhbPPJRa7A3rc3CBCHrREMVaYTS7s0Shw== X-MS-TrafficTypeDiagnostic: DM6PR01MB4490: X-LD-Processed: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4490; 31:8XAzirJO53lRUhXIkyYbLAt7r/Y/Frz3c0MTR+FZUNclQ4EtDbXivjuBOXpMeqOmgEGs17KoYIpFJwAoyIAPe3cGhwl4DzQ3OmunzNzs+sSRekHhzQBHjvN6+Lq6G7STNTPssXttqelQlpZ2VcN6pcJgEHMMiTQQpuG24WTkopG/F2iCh3edncGAGji6Z2EVaafb9MiqrcbFob6Hb7cYezVyjw782306VoNTPzFUy28=; 20:rbby+xK2aZ24fKeIGTt0kdY1DDpsvJOpURotdZndxOxbSWckiHTc5QmI2GkPA+zkU6wC0bkPv1O+YM6BBJ9II+ndCMHuhDYw5MI1N7tS77FjL+j778BK1u0XCwjd4DNWAlrnMdTr7UiDgU2c1Xvw+wpBMd5Dk5vVRJDyUzotyu5NWI9bsc2/POhnR+NMBWQF8k7UkRstEM+zHdTrQ0SswsxxptyZD7FTK+Ayb5mf8cbboG/q3VHD1rTbNX20p4yZ2UEbC7qm9le9mClLX/6/rjPoY2yka7RQrcOKq4MWf/LNZdL+H2VGuAB/Kj/33/lPIvd1zAtfXLfmQjFx0J5yHpPmKQbz5PgjDMuefr1ytD8C3JdEwG5G+u8UaLZoV4SLtM3BE094mgVTy748zrc9jCgnRqjExbemX4uLwESbBrrPbKyfzWVhfQiG/vGqlktzIqduihWf4FicHusshyo+cLgxctK6OkL/faKcMk7V6UfQNp9mw173adGkFT3EXgKAlkOejTMWHizIUf+rfItH1+19QkSxj2hFfaegoHdhrZWrFIN6bHFQnjBfOVWR+fYgbBzIMqXpOX8lfcFDr0JByYIR+I4FVUAGzbSnGe5l+k4= X-Microsoft-Antispam-PRVS: X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4490; 4:tCx693WHLD1aF8ogN2sFw1bCcWPEZ+2pBWahjeGTTX0SFgC7rEopZZJ5PHeKKhFQe8k57enzI3L6f8V/KC+oUGRBfrYjJCOJCM1pyiFEeXShniKeRnJZFVFJxqrYJDaftqAYxbtBl368oZuwGXhv2cQpThJrp7/0FkiJ9kENGnx9s7lfruX/EBEBpIIEyW/gG5p1I6rz4XhNQfh1TSPsAZ+Mii4y+xyfaozktjxZ9SqnSH3DrzVIqcq/Qu8pHNa9FzAkyxik3jWt+SsW/M1EVHbwd9hDxQiOkASxFa0nKqKj4hyK7S/NFZQo2xaXDf/e X-Forefront-PRVS: 0937FB07C5 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTZQUjAxTUI0NDkwOzIzOllrVjgrb0pWMDhzUzB3ZkN6bzVLUStGeDVG?= =?utf-8?B?b0ZhV09CL0JQbFZid1kvZEhPcHJjdFA0YzZZZnA0TXJJZG1VMjZBeHZEYnJF?= =?utf-8?B?Uy9mL1N6empzVXdhY2wvOXlaa0R5QzZiYlR0bnV2NHBDQ0dUWHpQNGlSODdP?= =?utf-8?B?WTB3bUJhMXpvU0RLbDZBcUhQelUxbXBBTW1uU2dUY3NBYlBreVowbENPYnI3?= =?utf-8?B?QlpxN3hMSjA3K2dDV0ZoZGdtL2JVNnFNcXFMZ1B5NkdxUzdxSVU4RlFOMjhh?= =?utf-8?B?aC8vYytBa2VMRmRsaTdoYXYwbnc5QWtCVXV4UXRZUUxFSXdKdVl0K2pUR1JC?= =?utf-8?B?UW80NDE0NWpHQTVqdzlxMm8xaFN6YUVDZjNZOWlOSnYyRFpQMVV1MnI1UWZk?= =?utf-8?B?SEVYdlBrRUFMdkFmRFNPbU5YZkFGT0hSMEVob1ZMZnRGamFvUUF5Ti95U29v?= =?utf-8?B?cU84eitxS1JodnM3NVdzZ00vWVVtSTFqSlJDTm1lU1cwdVJxV1ZMUE4vZkxy?= =?utf-8?B?YzNzZnI3TnNYS1Nzd1hXRmp0a3NFaXZBOUlSUGxvMHVEYnJBeDRzWDNuWW5m?= =?utf-8?B?VFF3eWZwZUg5QkZHM3MwbGlUNDlmUXoxa2Z0aXdESHgwblFrdDRUNlVaalJJ?= =?utf-8?B?NUZybnBIWUs5WHVHZVpNRytjdXQ0dHplbXlpanBoYWFENDlBWEhPS3lmTnc4?= =?utf-8?B?OFgwTVlFV2lHN3NzUEtXdllGbU5sOEllVXNGWkhpTXVRMm91T3VFdDFFSksx?= =?utf-8?B?RXRwWkFOUGJvYlU1dmdZMWRnY2NGcStvd2V3ZGovMDRoc1hzdHlxU05HYUdM?= =?utf-8?B?cGNPeUtzL3JacTMxOGhJemg3MFZpMXVVOFRqdE0zSmpCVGR2cDJRZ1pxeFAx?= =?utf-8?B?dzdDQ3B1QkNUWXhIaTRGWjZZVmQweEhGNHFMV1FTc2ZQbkRYU01POXZ0UlFn?= =?utf-8?B?YmNGN1hpL1BQb0l0NWtsYlo1ZjhzT0FCN1hka2tLcGRHVndManhlZHVNMTdi?= =?utf-8?B?UVE3YjdqV3J0c1NlZkJLVGQ0dU1ldjk5SFVtbksxQjZNTWhYbmpqMllnUTRW?= =?utf-8?B?SzBnV0tXb1NGZHlSb0FCdjg1Yi9YV3hEbEM4K3lZS3k3OWFmU28yWGFmVmxS?= =?utf-8?B?N251WXlvQVhwT2grNzN4MFNGdGJEY0w5aUNhaEk5T1d4RkZuKzNmN0ZDdDhF?= =?utf-8?B?MkNvRzFTUTJEd1grVDZhcGJFQzlrRUd1b295WkV4QlpZRlhhNVh6VGE1TG1i?= =?utf-8?B?aVJRb2pWT2x1RFROMjBSa3dMVXh6RHovdktYMUFRc0ZRdS8vd0UvNFVCQzRV?= =?utf-8?B?Q096RGpkSC9nMm8vRzhOdTVUcm55Q01IcXRRbkZ5MlhRbjNwSFRZS3RLcE1v?= =?utf-8?B?OGRpTlRIVCtYdmtxVGhLWGh4ZEZmL3k1UHlIRVFGdWtyS1hzRzJ6blZwS0FL?= =?utf-8?B?WUJIM0VvempGb0pPdFlHVWlSaGtHWm9NZU1qcWRzWktKM2x1TzlBdVVZOXhy?= =?utf-8?B?eVNxWDE3bTU0Qm1GWTd0VTdVamJJczBOU05McGxKQjdWYVdodk5Cczk0WWh6?= =?utf-8?B?dUdyNUpRZ0dDVXQ2cVJra0tHdFZtOVE0bUdoZFdvMnl2K2R0ZmdiL1hKS3BX?= =?utf-8?B?QldjcjRmTnZUL1JRczBqTy9OZXVtaVMvczduU0w0NkIwSVF4NXBCWFJnZmRW?= =?utf-8?Q?8IdpHFCcxrwe9j0Iabxtw9X5Up9/Ycjc7HuzZi/?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: XKf27EpHX9+gl806M4JxNFL6frGsGfTjp/y8vGRX/ImA/CYUan4QWhECstIu+/sDZE0RlP3HqINvp52AXV8UdY+Eb75ROt/R6HmGx8NgXhMO1DGMa23cDWHCRK1vg8gQZmx63E4f0V3uVdCkcQPJtPWZeMA+UrvevQdgZ8BY5hw6rg3xH5XV4QhBqgpeMP6JkeHtw5gAHT5WUFAga02PpiDE9/dFSHwDRn1MxbqwSXtn3M5s0v9OKmydsV/1ta4Zb9IB0OqHZfuXiyjongEtmQquBypyhdUh8vPxSz8MuriPi7XQ/nyHKO3TWx97JDpaYZvG0CUgOBurMXnewfJw5FA2PlcoAqNig+r6qb5cIWhgXEMSkRPxttLOfw1K4ISO1+g+oFIpGlGfOJYEuGjJcND53RzV8v3Zm8MCR9C4WBE= X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4490; 6:ADQKPmfXaiokMcH1hQToXBQRsNg9rNtuOKrghMVYgAXwSo+FDpLiNauJRqULEtxFwVk34YM9LBBPXhgUhh74xW2ogeHmdMLOsGiVNJOI4MeCbIcv11WnJmd3V1zbmpdHu+3eFEPkpU4tCZMRtP6V4pJgNmW62yXrxVzGChlY3TiTqwdlm6fEVwEGcuxVSbC8q3ceLCE/C/116Hn6wqPuBh/s5m9No0EUQZV9BmbObGsDxvBRqcbdU+y1G2GEZEUppOhhheaxsa3kzLck/jwSAqnszyc6T2HrVul1pP5I8AqbCS7eJxSYADAYXizUgXxtS895Y1vzfjp+9wB2f5aWMuzdA6nohHf5+yAeZdMQB9Yjg0h9n39k8fEH/0PGlCjszcND6c3jVyoBEk59B3DtCINMwkhSP0tY+LxaLgiUafZ2xwWBAp8s40pNmPqO8kmq+y6ateJSjADXpvimU5fD2A==; 5:xiEvxjNS0H4z3B15anuCoXN77HfkugiYdhoIC0da9DtBzMwtf2oY80VJJjomRYLPz2Z6xKdjQM+U6HpZbXg1ww58l1/VqVEzYLP3K5gadJHSHpt80kvyekuwDbTe4PrN6/pdPdHDhD5mWb7AvLJ+cIGqO16gwo4+O1hreJV9kxWqKKyIZ8XtLvwtq+OOr5stQq2cSq3DMJ4K6c9h5G/8LQ==; 7:8g7KQ/zE1P6pnGIKImw+PdWinLwIzll4Z/Tw4D8X09qAoZ1PzlRH/2Vcp6n3bGZXkAeLzvZUB9YpUjBheVb8rmqC/u/r0LDfVSz35DArKzVk2F/5Wj7/wwLivUn6W5Kf9MRiu/Kl2TRErXglmnVZiA== X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Feb 2019 16:52:56.5713 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6a0fc7d7-ea9a-4593-d574-08d689f80c3d 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: DM6PR01MB4490 Archived-At: Subject: Re: [kitten] AD review of draft-ietf-kitten-pkinit-alg-agility-03 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2019 16:53:03 -0000 On Wed, Jan 30, 2019 at 04:45:55PM -0600, Benjamin Kaduk wrote: > To name the input parameters, an abbreviated version of the ASN.1 > version of the KDF from [SP80056A] is described below, use [SP80056A] > for the full reference. > > [SP80056A] seems to call this a "KDM" and not a "KDF"; we probably want to > call out the terminology mismatch and perhaps also the section number > (5.8?). Also, the actual algorithm seems to be coming from Section 4 of > SP800-56C, not SP800-56A, if we want to be accurate about our reference. The draft reference was accurate for the original SP800-56A, but there has been some drift in revisions to the NIST document. Fortunately, none of the changes invalidate our formulation of the KDF. The revisions do seem to have introduced the term KDM as you say, perhaps to distinguish key derivation beginning with a DH shared secret from key derivation beginning with an existing key (SP800-108). However, the terms "key-derivation function" and "KDF" still appear in SP800-56C several times, such as at the top of section 4. So I didn't see a need to call out the terminology difference. I updated the references to account for the SP800-56 revisions, and changed the terminology in the abbreviated description of the KDF to match the revised NIST recommendations. > o The maximum hash input length is 2^64 in bits. > > I'm confused where this parameter comes from. On the one hand, that's an > absurdly huge value; on the other hand, why do we need to give a limit at > all? SP800-56C section 4.1 has max_H_inputBits as an implementation-dependent parameter. (The original SP800-56A had something similar.) It is only used for an error check. Since SHA-1 and SHA-2 hash functions do not limit the hash input size, we just need to set a value large enough not to trigger the error check. > If the supportedKDFs field is not present in the request, the kdf > field in the reply MUST be absent. > > Somehwere in here we should probably say that if the supportedKDFs field is > absent, implementations continue to use the RFC 4556 KDF (if they continue > at all). We might also give the KDC the option of rejecting the request, if it does not expect requests from old clients. (I didn't make that change in my revision as that wouldn't have been editorial, but I did clarify that the RFC 4556 KDF must be used.) I believe I addressed all of your other comments in the -04 update. From nobody Sun Feb 3 13:32:36 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 C737C128D0C; Sun, 3 Feb 2019 13:32:34 -0800 (PST) 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 rZ9aRuoM0gtf; Sun, 3 Feb 2019 13:32:32 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780091.outbound.protection.outlook.com [40.107.78.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 478E0128CF2; Sun, 3 Feb 2019 13:32:31 -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=KjnE3NbdH8wG+nNCGE+iwPs8yrn0BJlvUpKFpDOiUZw=; b=oNXbPLtOmvxSPXVyuhFpfOnTE0pDawzMKCjuU7xYU6CdMGYibsTrUhVvRdeItP+8xIQpwj3gbiMlSBhTlwHmM7FJyRjoE4JPwg3Z80opm8tdZkIOL0C5KIHHpIsESnpRlUPWuUFiW3AdqfCgUxttgRXtLRT0vz0bXUacZW4hw7s= Received: from BL0PR0102CA0043.prod.exchangelabs.com (2603:10b6:208:25::20) by BN6PR0101MB3187.prod.exchangelabs.com (2603:10b6:405:2c::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.22; Sun, 3 Feb 2019 21:32:25 +0000 Received: from CO1NAM03FT020.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::201) by BL0PR0102CA0043.outlook.office365.com (2603:10b6:208:25::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.17 via Frontend Transport; Sun, 3 Feb 2019 21:32:25 +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 CO1NAM03FT020.mail.protection.outlook.com (10.152.80.178) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.10 via Frontend Transport; Sun, 3 Feb 2019 21:32:24 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x13LWLZ3031041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 3 Feb 2019 16:32:23 -0500 Date: Sun, 3 Feb 2019 15:32:21 -0600 From: Benjamin Kaduk To: Greg Hudson CC: , Message-ID: <20190203213221.GC92608@kduck.mit.edu> References: <20190130224555.GE49072@kduck.mit.edu> <20190130224805.GF49072@kduck.mit.edu> <04550c84-f6e4-7799-195d-dff3f504ee33@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <04550c84-f6e4-7799-195d-dff3f504ee33@mit.edu> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(346002)(376002)(136003)(396003)(39860400002)(2980300002)(199004)(189003)(33656002)(50466002)(6862004)(2171002)(53416004)(1076003)(104016004)(6246003)(88552002)(4326008)(2906002)(97756001)(46406003)(16586007)(58126008)(786003)(316002)(478600001)(450100002)(36906005)(246002)(106002)(229853002)(54906003)(336012)(75432002)(426003)(26005)(8936002)(7696005)(26826003)(8676002)(86362001)(47776003)(106466001)(23726003)(55016002)(14444005)(11346002)(446003)(956004)(305945005)(486006)(476003)(6636002)(76176011)(126002)(356004)(186003)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR0101MB3187; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM03FT020; 1:PrtxwUqQrtiKO0EUalplmJPlWlRMU1SGng9/4zwO/sC7jHWMPNmWrveHn45BzS9gV5cC9K08rnOxdokZWDm7+G6Aijh6B2eUUckpqNrtrDk3GX40GWDaxUo4SA9b8tGAUmGhhmaFTyl7UZVkozvtZg== X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a8328c7e-81fa-4389-cfcd-08d68a1f16ed X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060); SRVR:BN6PR0101MB3187; X-Microsoft-Exchange-Diagnostics: 1; BN6PR0101MB3187; 3:FZXuSOO8/vJ31kdOiBlyu/YsrnruimEAoQLcKovKuL0A9Gaw/T8QXt9saJ6DOw5/YZSbHOj+szEzvPcTyND8IwIwyNC9Qud2mgMHP+wn8NKZ27XxUZFf2HZ81+lqxVcweJrfR/7yson3bJ6qQ50luHKCp1sbt+zTCuC7XksjBwXko8fFzAVe6xpydPWNoE/J/PZmewJxg5NYOJiJTTTbB8Bx3H8wRyB4cODcc0xPmcMpIAxrc8jwcwlU2M1wHQHZWPbZN9DKAkTj65FYQhX60TLJOmyZw4Et9jRw7uDOHyYIjfzqRle1EAL6qdrKPN+WSgtaMDvQu2NXxGMeb/6j0zCE8yBudwX0RRAhyYhCWdP45GyOcbMltp0DyhTVN3mk; 25:PNi5cy5k4PheWTbI1NpuR40XWd3OsI8UBhFBKNfZXzxyosajO7ZbwKDw4idfwGCUuasHpY4PZp6Miw3VI9pANYurvJ1ctoVXfMjVg5nAni6yZ7NdFKaRq7/j43bP2c6obQpVvlaP2Cg4Pr7a4xPDfBiVSrWvcbSJkyIxitL5W9hH9H8GZSBGD1HbC58HZBlqwOtTlKuvLQUoNukZXGkSIyYMYLv6BWce1+3L1WVcnIJkJ/bsAUq9XNPnKDoyiYnV/2JDD6juNRF0TBDRWzgUaaTr96vOFKmf5/Cglvine+Ukm1cGSDGMzDWPPHn3xPVa+7vhDZqHxveaBizpMUlCyg== X-MS-TrafficTypeDiagnostic: BN6PR0101MB3187: X-Microsoft-Exchange-Diagnostics: 1; BN6PR0101MB3187; 31:MG+tvvvVRb88XQVoTsVylLHpKeWoYa4Tq4FS9Tdl3w49EVq7cGnb+G37byBzAoSmIrXDgpTe5Il0Zn9kXboRkPQRVubHo76eJB7Lvcx1RUCEhBcjiLvBl50BIZ63nbgtIHxpvmnge36aJq4aZJp6ZLvkg4uoxGLFAnT1IYrqRijv42hQs1zELbQLm2MJ3VIYp7D54x7zPsH9bN6NMWpGyU8gcW9GcXbOt+LGZWbSRYw=; 20:H1r1MHvu55jJolCh7DzSYaH6gDm7tcz6Wv53hHvTLBFIdiM9UCgV/TdKYObSi1JOns7JqMNpV9HnfcB/PMABbx3RHT38vM8cPeItSLf+0qRnW77ARgyLZeT2T0AJgTgfCUCKnRKBvIaK+4/gGLcbCRKYJV2Zg79qVy99rbl3ODcA8qe+AcG0CQedpSrbwFylciJkFZudA3TgwKREv72/O53JBTw12xagUQMERYt/UJDoXEqTkWGdmxPRA5TDDH1BfWf2UwmhgdyjbHYWXTXC9UZj3FHm7P+eikPlSiy0UspwSIwq/bDKIf9IoX5rtjDQGyhe6I3k4A9HaFApAhAlEMosi0tJtkAqVALxRV8IrYy7EnNgGXPoSEAFOkR9aQrL7ChhkDFC55wdUCWzgnIGaG7MAYdHT3oePveDa6LsR2XsEqISpysJVtiFBCAQL9zCOCT6VWI7B7RUYfj8RgwCvlJO6iuDjJKRt9dyJSb3ONv8YtfA4AqFpmLIWu6rsdZOJMQ++30s9OPyOLXXopk13V3Y8Zd9ILWaZscttq0pWCYrbXGYvn/TytqND9jzcUM9Z65h8j/PBeEhazOXn7EQk9iuKxDkwEJztitC5ovq5OE= X-Microsoft-Antispam-PRVS: X-Microsoft-Exchange-Diagnostics: 1; BN6PR0101MB3187; 4:I21btPoyaWmbHcCHW9amhjYjnjHyoR8N6ZBn1KBHrBempXaNVg3NovgLmjzl/tpjyc+Yq5nIys3Jy+4t8BE9zn39+hIKLlFaz/RJ2J1E68Smvz7xTevscdbMARBAiVD3ur6/pp+se4A/yGz+h7ObY3B4vhk5CbkSwALRJwPv8EYpxAi3G65EPGrSKJf/6H6BRySbzfBCEzPPFkGcji7t3c0Y8PplqR7ECPUn92GwbfZ+oQdRwh7MvIB5lSaX7m7e8Hv3MLF2DlzoT0i8Oa0vht8fV28ql59D5uuw3Hvu7Ebgv4gJCrJcvrftp8BzVbiN X-Forefront-PRVS: 0937FB07C5 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN6PR0101MB3187; 23:4VlnPSnLASl0PXm5IvMdOCOFkee9IANPXlChi91?= =?us-ascii?Q?sShWQGpj4KoMi2HJbQgl45Pfn0qmHUHuMYG9m47FbLRAAffVy+61rAAxuH7l?= =?us-ascii?Q?kUjI+TjRJjFTMg/pjJrbMx217Wm26qfJXd+4Bi9EK/uBuSP2JA9DouXpiHvm?= =?us-ascii?Q?u+YPbBsDOMcWX7R9Gi2X4buXxtDmfLhknu1G0ERjyyNvam9kIuOZTbJW/Rz8?= =?us-ascii?Q?4zavVDg401kkVybZ8OFXoVYAxYoImK+0StGzyGW56Pbb3PzSds423iq6jqpk?= =?us-ascii?Q?y98uqoG7aJjjFbFb7ZDuTW3Af4zfTC+Ai9SPYePbtIJLMZrZ7RDUaKCh6/z0?= =?us-ascii?Q?NCrhcLFm8jkIYJVdZtYA39jcLlyp8se7mQyz9/BJPQn3/CFvcsu7djD/FyIv?= =?us-ascii?Q?3jS5E0ZQAs4R5soTg4bcnyv7MJLHCe02tB2wiRdo8nCmkUZe1Xs3sjkQKEAF?= =?us-ascii?Q?iVlEI2xba4ZwpAv1JATVVDmuxqVdDhNrv+nvTG5A+lojX0QLTsaOB/g6K7XE?= =?us-ascii?Q?ndYjLWqYymsweCmukHlkZbz3sbO1KoxViEPMxO8+VhW40ebb08Fbpst4EAeN?= =?us-ascii?Q?XhCy7YBeAzcEeasfgAYDKOc+Y6HxLU+SkSjUwcY2v6fupxfPLlWJ6lS6Txls?= =?us-ascii?Q?EwJ5KRLtzExMK/f/esZMIxMVYFiuvjbhOPL4gne3I9wK/8jJa5fxggF47UlA?= =?us-ascii?Q?al5BCkeX0B4uGocv0xDKEY7YGmpngQ/lwGztvbem6qbqNNPTlSsQFYEHRo+X?= =?us-ascii?Q?84yILCQM8PTXIbTrDIEvaM6dG/piQkw+IBKXUS+37FTsQgUaJEGOJM1foxpx?= =?us-ascii?Q?6jyOncw9KfW7qXoYaBphlocokbwm69lkQlWy9b+TOveJeSYBc3J/MUtFWXjH?= =?us-ascii?Q?WDnp7XAk5JsQ9gQifAGERke2ktSgSktle7b4ioh3SaMLsy374dDo/CgYbbYw?= =?us-ascii?Q?sHtfh4zoqW5SIPvR9NHK3k/+J6k79WUDsBG8DiEuyhjgP9nw5xxltsbcMy04?= =?us-ascii?Q?ile9YD/7tIsVxVbZSrNAqmUcqpYMcHyVgXFAEyOVnHMXKinpStxD4KPQ3ArQ?= =?us-ascii?Q?J0PY+lpFukIybG/GEdlh/5fitHrUxn+tE3XBb4wN5hx5pW+dCHAc9zUKOXM+?= =?us-ascii?Q?OCu613N+g/1lt5qhnN3LMpH9QTZ57bolvqbRHgOyJew1Sc4+1Fg8CAMsN63P?= =?us-ascii?Q?HvajoNEINn57yy03TJ0MdBjYyapFtgSwTUojqjgfHNQcR1VkItRrlZhibMpK?= =?us-ascii?Q?5GDatmwjSPAt10ebcMNhT/JmeeBMnC+AlHAp3hwkp?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: 9m+Jwh2UAXfjoqD/CGNHPICPfvWIs4PJ7hAbRHmy5nJTPqRwR1cw5Sfpj3YCri5/x0XJLBcR7upD2cvJybtB8qwITRohADgPdZdOf6umYol/+9M4v8uZaVcheBGVd1qtuNiWVhv8tuUiZBxAxePmRIsB9nrqcKmZ/tQtA+AkNhQ/EdsE96BVrarSjd1i55pWiKqBehXa50Vtl8xLW0Fd/p82UK8an9OBAlKW40Nzu6B+0rsSwtlHdZvqBs5L69TJr11+7c9Kq6MQnXxvY1QdVxclzV/xbSoIP+OjQBPpr0BkmoUV2YKROfWZa8kuC5iAcYjTtOIoBPxBggEV65iK6hsqInSxD9IckhtHpCnwOV6gD5azITiPVbEoQGfzz8T5icU2jNCCoaK+gELD4yVZfwCl3jvX/4CTcefDf5960z8= X-Microsoft-Exchange-Diagnostics: 1; BN6PR0101MB3187; 6:EUv+J8h91Z1n6eJHCzn0qwV0A9f0Y1gidWJ4IvEtsdGBGXCORhLVSbkeMH7/xwhI/dVK95C8kYvpKmieYHrlFwVixMR8W9RdeIv+9llWibpWbWfLU1Pcs6Cb13cqxpQiwEuRzKlV7N4fvt3Rry3mkqlMUwlb+0joF9Iu9ywXbVwkHoqmn3Yh5y6PP+JbWjKqwVbrft3NnQ4nT8ODk/BYabocxVeloPEoYJjWHdv9esolIud83kKnZN+RDEkik4PwpTROISxJQnyBVy+7QWG4RSEMAldzR70mtKnHFDY271Htyz+3UXKcrVpk3wKqwHbPbRB0qbFPyG1yzI5m6V7X7LvyI7O+KNMGUszKnAnxQYc8I9Jb37BZrmeigecaWC+ww308BAIM0ZD4LZBEDJAe6F4DfzzSsWa+XFVGPluzdeeooEjapKZ0E6Ce4dmalLIM4gMRrTDkjoETWagLYOd4+Q==; 5:mq369EiNGrcyeEBrpkiLzefPeQ1Vl42fUL73ZXJ4XqbRnEDiI7h/P4026fX07tYcRo+IAFZRw83mMlAg1wDa5Ejf7HKW7jZNQ7oXw61D3PQSmi6AB35V1Ce8YcwTy5zPfHU+hDVAcEKQiuENm8r+BrT89mIj5rJAeGgyeNP37WDGAE/Xg3pC2yDwk1l7nMqsbleq5gLqb4hJQslxh5r88Q==; 7:2PQ01W5wYMNwrmWeLEe743jEFfW+W2uYJdvAmSDwGpGzAF9LHbdMR1ARf65iVY0tAu0ERbbQzSEuiR8aYrwJSS3bHzl0GbgXQO3elCYKWiin5ci76k1Rbjenh7M+rvwY1NzF9NkSLT41/GTJ3G+7yw== X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Feb 2019 21:32:24.9580 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a8328c7e-81fa-4389-cfcd-08d68a1f16ed 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: BN6PR0101MB3187 Archived-At: Subject: Re: [kitten] AD review of draft-ietf-kitten-pkinit-alg-agility-03 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2019 21:32:35 -0000 On Sun, Feb 03, 2019 at 11:52:54AM -0500, Greg Hudson wrote: > On Wed, Jan 30, 2019 at 04:45:55PM -0600, Benjamin Kaduk wrote: > > To name the input parameters, an abbreviated version of the ASN.1 > > version of the KDF from [SP80056A] is described below, use [SP80056A] > > for the full reference. > > > > [SP80056A] seems to call this a "KDM" and not a "KDF"; we probably want to > > call out the terminology mismatch and perhaps also the section number > > (5.8?). Also, the actual algorithm seems to be coming from Section 4 of > > SP800-56C, not SP800-56A, if we want to be accurate about our reference. > > The draft reference was accurate for the original SP800-56A, but there > has been some drift in revisions to the NIST document. Fortunately, > none of the changes invalidate our formulation of the KDF. > > The revisions do seem to have introduced the term KDM as you say, > perhaps to distinguish key derivation beginning with a DH shared secret > from key derivation beginning with an existing key (SP800-108). > However, the terms "key-derivation function" and "KDF" still appear in > SP800-56C several times, such as at the top of section 4. So I didn't > see a need to call out the terminology difference. > > I updated the references to account for the SP800-56 revisions, and > changed the terminology in the abbreviated description of the KDF to > match the revised NIST recommendations. > > > o The maximum hash input length is 2^64 in bits. > > > > I'm confused where this parameter comes from. On the one hand, that's an > > absurdly huge value; on the other hand, why do we need to give a limit at > > all? > > SP800-56C section 4.1 has max_H_inputBits as an implementation-dependent > parameter. (The original SP800-56A had something similar.) It is only > used for an error check. Since SHA-1 and SHA-2 hash functions do not > limit the hash input size, we just need to set a value large enough not > to trigger the error check. > > > If the supportedKDFs field is not present in the request, the kdf > > field in the reply MUST be absent. > > > > Somehwere in here we should probably say that if the supportedKDFs field is > > absent, implementations continue to use the RFC 4556 KDF (if they continue > > at all). > > We might also give the KDC the option of rejecting the request, if it > does not expect requests from old clients. (I didn't make that change > in my revision as that wouldn't have been editorial, but I did clarify > that the RFC 4556 KDF must be used.) > > I believe I addressed all of your other comments in the -04 update. Thanks for all these updates (and explanation of non-updates); I've gone ahead and requested the IETF Last Call. -Ben From nobody Sun Feb 3 18:09:24 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 B5A3B126F72; Sun, 3 Feb 2019 18:09:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk CC: kitten-chairs@ietf.org, Robbie Harwood , rharwood@redhat.com, kitten@ietf.org, kaduk@mit.edu, draft-ietf-kitten-pkinit-alg-agility@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <154924616370.10957.10456720727697635377.idtracker@ietfa.amsl.com> Date: Sun, 03 Feb 2019 18:09:23 -0800 Archived-At: Subject: [kitten] Last Call: (PKINIT Algorithm Agility) to Proposed Standard 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: Mon, 04 Feb 2019 02:09:24 -0000 The IESG has received a request from the Common Authentication Technology Next Generation WG (kitten) to consider the following document: - 'PKINIT Algorithm Agility' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-02-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document updates PKINIT, as defined in RFC 4556, 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-kitten-pkinit-alg-agility/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-kitten-pkinit-alg-agility/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Feb 5 10:42:25 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 CC9C6124BAA; Tue, 5 Feb 2019 10:42:23 -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.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: kitten@ietf.org Message-ID: <154939214378.32255.10107864029530247720@ietfa.amsl.com> Date: Tue, 05 Feb 2019 10:42:23 -0800 Archived-At: Subject: [kitten] I-D Action: draft-ietf-kitten-channel-bound-flag-04.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: Tue, 05 Feb 2019 18:42:24 -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 : Channel Binding Signalling for the Generic Security Services Application Programming Interface Authors : Robbie Harwood Nicolas Williams Filename : draft-ietf-kitten-channel-bound-flag-04.txt Pages : 9 Date : 2019-02-05 Abstract: Channel binding is a technique that allows applications to use a secure channel at a lower layer without having to use authentication at that lower layer. The concept of channel binding comes from the Generic Security Services Application Programming Interface (GSS- API). It turns out that the semantics commonly implemented are different than those specified in the base GSS-API RFC (RFC2743), and that that specification has a serious bug. This document addresses both the inconsistency as-implemented and the specification bug. This Internet-Draft proposes the addition of a "channel bound" return flag for the GSS_Init_sec_context() and GSS_Accept_sec_context() functions. Two behaviors are specified: a default, safe behavior reflecting existing implementation deployments, and a behavior that is only safe when the application specifically tells the GSS-API that it (the application) supports the new behavior. Additional API elements related to this are also added, including a new security context establishment API. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-channel-bound-flag/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-kitten-channel-bound-flag-04 https://datatracker.ietf.org/doc/html/draft-ietf-kitten-channel-bound-flag-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-channel-bound-flag-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 8 14:57: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 BBDD4131066 for ; Fri, 8 Feb 2019 14:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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=cridland.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8gsVypjlO85 for ; Fri, 8 Feb 2019 14:57:05 -0800 (PST) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 C1179131069 for ; Fri, 8 Feb 2019 14:57:04 -0800 (PST) Received: by mail-lf1-x131.google.com with SMTP id l142so3769762lfe.2 for ; Fri, 08 Feb 2019 14:57:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:from:date:message-id:subject:to; bh=DC5okGZXUGjBScb/4ZFXAvzx05K/Zy46v5GSsTbYobU=; b=elQYdWdxmu4uia1feXW1gJ8fByjJMeuOivC/bAQKssqhoYc5KePwEm2Puj3e6XL0+f EEGcXM5j5g783vvexIHfbDxhX391tB1k5kWUF20cGlPyHAI7nFDV4Ow7lsPETSAZLiJl m4m/pq125ZWt23dIelzbHipgBBeQTGKYMnMy0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=DC5okGZXUGjBScb/4ZFXAvzx05K/Zy46v5GSsTbYobU=; b=BiQqcMF1om2lNCQWAIHsQy72Hxtvrr1cAvS7VC2jzlnAGqp4uyarup4pzMXdYtw/ex iK+w5JD5K2jFMNb8TJtVBZE2p8sf1jVb2v/Qjk3W8+EiGxXr5n80mkTHOsnBbKz3VkkM U71P4xcGk4fP5UeOX7mF/8YfHp/nbpjD4Ee0n50J2+46X5I0U1alIGe/bwrBoB3wOk0n 5fhOd/2pe7nHkP3kQUa8OVKeWOdLpErK9mkW0YnmTJTYLc7XwzxndDz/oqwlru7oTbTy ha3EyA6TZjfuCUH1rKnd1ds/K2eSHbNxj+dR3WmiCq2qcEDx2CfUEmkFPDdz2/NA0jLW ulqw== X-Gm-Message-State: AHQUAuYGX/mcDqkWBkwO5Ky6ety1lGKWw3ykAp2f8gh8YmERB09BU/pD WJh+Q4TuHvW8pSyzfuDfv+QcVvVGecJPhuQeDIcE6tdFFIQ= X-Google-Smtp-Source: AHgI3IbfSUZCboXL2SVM6iqo6bSHOYZ1GGiwRxeFRzb4RHey/G7A9fk75Fn4wlDz7gHB38kph+cqOI1vLUI9LmMD5UY= X-Received: by 2002:a19:200b:: with SMTP id g11mr14821051lfg.58.1549666622527; Fri, 08 Feb 2019 14:57:02 -0800 (PST) MIME-Version: 1.0 From: Dave Cridland Date: Fri, 8 Feb 2019 22:56:51 +0000 Message-ID: To: kitten@ietf.org Content-Type: multipart/alternative; boundary="0000000000008e744e058169e0cf" Archived-At: Subject: [kitten] Review of draft-ietf-kitten-channel-bound-flag 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 Feb 2019 22:57:09 -0000 --0000000000008e744e058169e0cf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, Robbie asked me to look over the aforementioned draft, and so I did, and sent him the notes below. You'll be able to readily tell that I don't know GSS-API from a bar of soap, but I hope they're useful nonetheless. He asked me to send them to the list, so here they are. I realise, re-reading them, that I seem a little grumpy. The content still stands, I think, but the tone was not intended, sorry! -- a) General comment - I'm a native English speaker, and I find parsing the double-negative "not when the initiator provides none" incredibly hard. Is this necessary phrasing, or could this be changed to be a bit more readable= ? For example, at the beginning of page 2: However, GSS-APIv2u1 [RFC2743 ] does not specify channel binding behavior when only one party provides provides none. In practice, some mechanisms (such as Kerberos [RFC4121 ]) ignore channel bindings when the acceptor provides none, but not when the initiator provides none. Note that it would be useless to allow security context establishment to succeed when the initiator does not provide channel bindings but the acceptor does, at least as long as there's no outward indication of whether channel binding was used! Since the GSS-APIv2u1 does not provide any such indication, this document corrects that flaw. So, I understand from this: * There is undefined behaviour when only one party supports channel binding. I think. Note typo in the first sentence. * In practice, if an acceptor does not provide a channel binding, some mechanisms ignore channel bindings entirely, such as Kerberos. * Conversely, if the initiator does not provide channel bindings, but the acceptor does, channel bindings are typically not ignored. I have no idea what this means in practice - does authentication fail? I get that impression from the later paragraphs. * I don't understand the note. I think it says: This latter behaviour is sensible, since to allow security context establishment to succeed in this case would be problematic absent any indication of whether channel binding was used. Maybe? But I note that's also what this document recommends later in =C2=A73, so I suspect I'm wrong. * There is no such indication in GSS-APIv2u1. Is that right? b) Empty Contexts It's a mystery to me why this is in this document. The rationale isn't explained at all. It might be that this is obvious to anyone indoctrinated into the dark art of GSS-API, which I'm certainly not. But it's first mentioned in =C2=A71.1 as if it were a necessary extension for addressing t= he problems described in =C2=A71. Is GSS_Set_context_flags() always to be call= ed with an empty context? c) Typographical errors * =C2=A71, Page 2, "provides provides" (as noted before). * =C2=A73, Page 7, "This strong sugestion" -- Further notes: I'm still confused about the outcome where the Initiator supports channel bindings but does not support the flag, and the Acceptor does not support channel bindings. In SCRAM, this case is special, and the Initiator ends up passing a channel binding essentially saying it could have done it if you'd asked. This allows an Acceptor to determine if a downgrade attack were in effect or not. I have no clue if this is common in GSS-API. In any case, if an Initiator is unable to know if the channel bindings were used or not, I agree with the initial assessment that this is problematic. On that basis, I'm uncomfortable with the suggestion that an Acceptor SHOULD ignore the channel bindings and continue anyway - but there are clear trade offs between interoperability and security here. I would therefore suggest this recommendation is downgraded to OPTIONAL (ie, a MAY), and the pros and cons spelt out clearly. Dave. --0000000000008e744e058169e0cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Robbie asked me to look over th= e aforementioned draft, and so I did, and sent him the notes below. You'= ;ll be able to readily tell that I don't know GSS-API from a bar of soa= p, but I hope they're useful nonetheless.

He a= sked me to send them to the list, so here they are. I realise, re-reading t= hem, that I seem a little grumpy. The content still stands, I think, but th= e tone was not intended, sorry!

--

<= /div>
a) General comment - I'm a native English speaker, and I= find parsing the double-negative "not when the initiator provides non= e" incredibly hard. Is this necessary phrasing, or could this be chang= ed to be a bit more readable?

For example, at the = beginning of page 2:

   H=
owever, GSS-APIv2u1 [RFC2743] does not specify channel bi=
nding
   behavior when only one party provides provides none.  In practice,
   some mechanisms (such as Kerberos [RFC4121]) ignore channel bindings
   when the acceptor provides none, but not when the initiator provides
   none.  Note that it would be useless to allow security context
   establishment to succeed when the initiator does not provide channel
   bindings but the acceptor does, at least as long as there's no
   outward indication of whether channel binding was used!  Since the
   GSS-APIv2u1 does not provide any such indication, this document
   corrects that flaw.

So, I understand from this:
* There is undefined b= ehaviour when only one party supports channel binding. I think. Note typo i= n the first sentence.
* In practice, if an acceptor does not prov= ide a channel binding, some mechanisms ignore channel bindings entirely, su= ch as Kerberos.
* Conversely, if the initiator does not provide c= hannel bindings, but the acceptor does, channel bindings are typically not = ignored. I have no idea what this means in practice - does authentication f= ail? I get that impression from the later paragraphs.
* I don'= ;t understand the note. I think it says: This latter behaviour is sensible,= since to allow security context establishment to succeed in this case woul= d be problematic absent any indication of whether channel binding was used.= Maybe? But I note that's also what this document recommends later in = =C2=A73, so I suspect I'm wrong.
* There is no such indicatio= n in GSS-APIv2u1.

Is that right?

b) Empty Contexts

It's a mystery to me= why this is in this document. The rationale isn't explained at all. It= might be that this is obvious to anyone indoctrinated into the dark art of= GSS-API, which I'm certainly not. But it's first mentioned in =C2= =A71.1 as if it were a necessary extension for addressing the problems desc= ribed in =C2=A71. Is GSS_Set_context_flags() always to be called with an em= pty context?

c) Typographical errors
* =C2=A71, Page 2, "provides provides" (as noted befo= re).
* =C2=A73, Page 7, "This strong sugestion"

--

Further notes:

I'm still confus= ed about the outcome where the Initiator supports channel bindings but does= not support the flag, and the Acceptor does not support channel bindings. = In SCRAM, this case is special, and the Initiator ends up passing a channel= binding essentially saying it could have done it if you'd asked. This = allows an Acceptor to determine if a downgrade attack were in effect or not= . I have no clue if this is common in GSS-API.

In any case, if an Initiator is u= nable to know if the channel bindings were used or not, I agree with the in= itial assessment that this is problematic. On that basis, I'm uncomfort= able with the suggestion that an Acceptor SHOULD ignore the channel binding= s and continue anyway - but there are clear trade offs between interoperabi= lity and security here.

I would therefore suggest this recommendation is downgra= ded to OPTIONAL (ie, a MAY), and the pros and cons spelt out clearly.

Dave.
--0000000000008e744e058169e0cf-- From nobody Fri Feb 15 11:39:54 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 C62A2130FC7 for ; Fri, 15 Feb 2019 11:39:52 -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 ZctWi8aoGI_h for ; Fri, 15 Feb 2019 11:39:49 -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 B60F4130FC4 for ; Fri, 15 Feb 2019 11:39:49 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1C3C61244E1; Fri, 15 Feb 2019 19:39:49 +0000 (UTC) Received: from localhost (ovpn-112-52.rdu2.redhat.com [10.10.112.52]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9ACAD5C234; Fri, 15 Feb 2019 19:39:48 +0000 (UTC) From: Robbie Harwood To: Dave Cridland , kitten@ietf.org In-Reply-To: References: Date: Fri, 15 Feb 2019 14:39:45 -0500 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.38]); Fri, 15 Feb 2019 19:39:49 +0000 (UTC) Archived-At: Subject: Re: [kitten] Review of draft-ietf-kitten-channel-bound-flag 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, 15 Feb 2019 19:39:53 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dave Cridland writes: > Hi all, > > Robbie asked me to look over the aforementioned draft, and so I did, > and sent him the notes below. You'll be able to readily tell that I > don't know GSS-API from a bar of soap, but I hope they're useful > nonetheless. Thanks Dave! > a) General comment - I'm a native English speaker, and I find parsing > the double-negative "not when the initiator provides none" incredibly > hard. Is this necessary phrasing, or could this be changed to be a bit > more readable? > > For example, at the beginning of page 2: > > However, GSS-APIv2u1 [RFC2743 > ] does not specify channel > binding > behavior when only one party provides provides none.In practice, > some mechanisms (such as Kerberos [RFC4121 > ]) ignore channel bindings > when the acceptor provides none, but not when the initiator provides > none. Note that it would be useless to allow security context > establishment to succeed when the initiator does not provide channel > bindings but the acceptor does, at least as long as there's no > outward indication of whether channel binding was used! Since the > GSS-APIv2u1 does not provide any such indication, this document > corrects that flaw. > > > So, I understand from this: > * There is undefined behaviour when only one party supports channel > binding. I think. Note typo in the first sentence. Yes. Suggested first sentence language: However, GSS-APIv2u1 [RFC2743] does not specify channel binding behavior when only one party provides them. > * In practice, if an acceptor does not provide a channel binding, some > mechanisms ignore channel bindings entirely, such as Kerberos. Yes. In general it seems like the phrase "provides none" is confusing - is that right? How do you feel about replacing it with language more like "when only provided by one party"? > * Conversely, if the initiator does not provide channel bindings, but > the acceptor does, channel bindings are typically not ignored. I have > no idea what this means in practice - does authentication fail? I get > that impression from the later paragraphs. Yes - per section 3, the acceptor fails to establish a security context. > * I don't understand the note. I think it says: This latter behaviour > is sensible, since to allow security context establishment to succeed > in this case would be problematic absent any indication of whether > channel binding was used. Maybe? But I note that's also what this > document recommends later in =C2=A73, so I suspect I'm wrong. Nico, do you have comments here? > * There is no such indication in GSS-APIv2u1. Yes - specifying the behavior here is (in my view) more important than which way we specify it. > b) Empty Contexts > > It's a mystery to me why this is in this document. The rationale isn't > explained at all. It might be that this is obvious to anyone > indoctrinated into the dark art of GSS-API, which I'm certainly > not. But it's first mentioned in =C2=A71.1 as if it were a necessary > extension for addressing the problems described in =C2=A71. Is > GSS_Set_context_flags() always to be called with an empty context? Good point. It's valid to call with a non-empty context as I understand (maybe Nico can speak more on this?), but the important attribute is ret_flags_understood, which there isn't currently a way to convey. And then just doing it this particular way is based on how the Java bindings work (1.1). How about this for text in 1.1: The design for signalling application flag support and empty contexts is based on the Java Bindings of the GSS-API [RFC5653]. We introduce a new function GSS_Set_context_flags() for applications to instruct the GSSAPI implementation what flags they understand. However, since the understood flags information needs to be present before GSS_Init/Accept_sec_context() are called, we also introduce a notion of empty contexts, and begin introduction of additional context inquiry and mutation functions, which eventually will also allow for simplified stepping to replace the GSS_Init/Accept_sec_context() loop. > c) Typographical errors > > * =C2=A71, Page 2, "provides provides" (as noted before). > * =C2=A73, Page 7, "This strong sugestion" Agreed, will fix. > Further notes: > > I'm still confused about the outcome where the Initiator supports > channel bindings but does not support the flag, and the Acceptor does > not support channel bindings. In SCRAM, this case is special, and the > Initiator ends up passing a channel binding essentially saying it > could have done it if you'd asked. This allows an Acceptor to > determine if a downgrade attack were in effect or not. I have no clue > if this is common in GSS-API. Interesting. This doesn't sound like the kind of idiom we have elsewhere in GSSAPI (not that that's necessarily a bad thing) > In any case, if an Initiator is unable to know if the channel bindings > were used or not, I agree with the initial assessment that this is > problematic. On that basis, I'm uncomfortable with the suggestion > that an Acceptor SHOULD ignore the channel bindings and continue > anyway - but there are clear trade offs between interoperability and > security here. > > I would therefore suggest this recommendation is downgraded to OPTIONAL > (ie, a MAY), and the pros and cons spelt out clearly. We're talking about the third bullet in section 3, right? Whenever the initiator application has a) provided channel bindings to GSS_Init_sec_context(), and b) not indicated support for the ret_channel_bound_flag flag, then the mechanism SHOULD NOT fail to establish a security context just because the acceptor failed to provide channel bindings data. This strong sugestion is for interoperability purposes, and reflects actual implementations that have been deployed. The difference between SHOULD NOT / MAY NOT isn't particularly important to me; Nico, do you have feelings in this regard? Thanks, =2D-Robbie --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAlxnFYIACgkQJTL5F2qV pEINgA//TfIvPgYAxqvEkkjWRma9KS19bzykiS9oDUoM3y/jWN/OfKcGuKqDE/e4 StFM5ROiod4ZAyHDr+40IKTrwX3LTuFXRbtZ4GmdMk8dXQzZ9dC6ltW54iM4KzZC 705Q2CJaXV25aGI994ExDPiUpLF0OgoFVvUwZffSIyqV9OKR1lLvhf6jYhY2PBu3 F3C0sMCZqFPmrwYXmlpuGtutL6ObfWzG2tJahCqPjQeNYk0W62fN0CwvQ+mTALyA UxNbPJ1pgbgu/x5l0y9PGsdZP0p628U2Sa6HImyusDDFFgiyMguQPDrgIYuVi6Lf RHaxKPqH2wNWMJAgGTooqhldUaFzFmaXixB2gHfat31UA/RrM0tCrKPFUAp7+5Aw 4jLtoJiZx/cfGPmIQcOaQYqxmg2VYBWFkURd6TzyYQfZ7N1xYeH4QhnjkgFdfrRv GOYDHHdU78ZdHdCzRkH51uXIXYjmSvdDKZ0feIPrp39tQ5991pzDsxSfE1V4Ys20 sGJrG0wwJGft5Knimlx8jm//NvFg3KPYr5tVVHFf4xRc+pJ5oqVxg9WZKSzufh0C KieZBk7rQjx0UdFhktF+hccCNF+G7kDjOJJH/KL3Su1YXaMGwhBD7QoYePUWWa05 aM7VgmVPr/7v4gdxfZodxcfiEGgEdqjjxchtJxWaX2kOIZHmIQI= =u47p -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Feb 15 13:47: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 94DA71310F6 for ; Fri, 15 Feb 2019 13:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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=cridland.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHXuFcIY3aLA for ; Fri, 15 Feb 2019 13:47:25 -0800 (PST) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 BFD581310E6 for ; Fri, 15 Feb 2019 13:47:24 -0800 (PST) Received: by mail-lf1-x12b.google.com with SMTP id u21so8281791lfu.1 for ; Fri, 15 Feb 2019 13:47:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5W+s9LSXQD4VxkHvLErWtUXjAKVg5O9IGG95QkShyxw=; b=OwDbhUua1EskyQITuhIo7W9+aE92SCEoLuzENuUT4DWfVQkoYOIvAKst6h4SC90QEA E2h/JOxmNSNGKn7MbSrFJk+2EZ1iKLRMptoceT5x51wKV0dpAiY7WC9HcoblbJNY8q+0 FTesNpgsHKCAOL/FLjHWiruef6Q3IicG2fyHk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5W+s9LSXQD4VxkHvLErWtUXjAKVg5O9IGG95QkShyxw=; b=SzSvwij4M9tjQ/AHzVk8tVKsIpF9HTiEhmR9/hOYQ2Xsf0NBNdjhzVmQK1SP9hKdUp JZITpmzzARiiVVEmMr8ZHQYFDJr7ej2GVIy8LTDP7BexY1PUgGyukvmOulhz6vbKSYga EWgLM57jpcQU4UROsZN4hc9UkgR1k+y8E/pTZb3fJucakOkgoJR850VERfvwxPC2lkhC MNqFXHhfMN0TLKAmkOiCUHeJNbFFud4IvPUIf01/iFioO1bxOGXTZOmESETHAooHfK6R bISUDbBaO717BTNCtmu+2cn/kgUrZcqdEVzryYdyeOGWz0HjSNf/P/4k7qlfsiPTVIPp tgKg== X-Gm-Message-State: AHQUAuYupTaWYTw5h26f/B9hhRAXcHBrQ8He5Q+IeQ7uclkp+vmU5DOi yNY/p4eErehaN+5zxgWasVQbZDwyFMMNX8f82EZJFQ== X-Google-Smtp-Source: AHgI3IbcE81fruQoG8FYnNk1YPjA2D+LAOjbufztZo5Ukgf7BL0LkR/Qvfgsuou9XLsgD8bmn2hYudkCJGlWDza7sHM= X-Received: by 2002:ac2:54a5:: with SMTP id w5mr7189244lfk.147.1550267242788; Fri, 15 Feb 2019 13:47:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dave Cridland Date: Fri, 15 Feb 2019 21:47:12 +0000 Message-ID: To: Robbie Harwood Cc: kitten@ietf.org, Nico Williams Content-Type: multipart/alternative; boundary="000000000000506adc0581f5b810" Archived-At: Subject: Re: [kitten] Review of draft-ietf-kitten-channel-bound-flag 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, 15 Feb 2019 21:47:29 -0000 --000000000000506adc0581f5b810 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 15 Feb 2019 at 19:39, Robbie Harwood wrote: > Dave Cridland writes: > > > Hi all, > > > > Robbie asked me to look over the aforementioned draft, and so I did, > > and sent him the notes below. You'll be able to readily tell that I > > don't know GSS-API from a bar of soap, but I hope they're useful > > nonetheless. > > Thanks Dave! > > > a) General comment - I'm a native English speaker, and I find parsing > > the double-negative "not when the initiator provides none" incredibly > > hard. Is this necessary phrasing, or could this be changed to be a bit > > more readable? > > > > For example, at the beginning of page 2: > > > > However, GSS-APIv2u1 [RFC2743 > > ] does not specify channel > > binding > > behavior when only one party provides provides none.In practice, > > some mechanisms (such as Kerberos [RFC4121 > > ]) ignore channel bindings > > when the acceptor provides none, but not when the initiator provides > > none. Note that it would be useless to allow security context > > establishment to succeed when the initiator does not provide channel > > bindings but the acceptor does, at least as long as there's no > > outward indication of whether channel binding was used! Since the > > GSS-APIv2u1 does not provide any such indication, this document > > corrects that flaw. > > > > > > So, I understand from this: > > * There is undefined behaviour when only one party supports channel > > binding. I think. Note typo in the first sentence. > > Yes. Suggested first sentence language: > > However, GSS-APIv2u1 [RFC2743] does not specify channel binding > behavior when only one party provides them. > > That works. > > * In practice, if an acceptor does not provide a channel binding, some > > mechanisms ignore channel bindings entirely, such as Kerberos. > > Yes. In general it seems like the phrase "provides none" is confusing - > is that right? How do you feel about replacing it with language more > like "when only provided by one party"? > > I think "provides none" is confusing - it's not a natural English formation. "when only provided by one party" etc seem more understandable to me. > > * Conversely, if the initiator does not provide channel bindings, but > > the acceptor does, channel bindings are typically not ignored. I have > > no idea what this means in practice - does authentication fail? I get > > that impression from the later paragraphs. > > Yes - per section 3, the acceptor fails to establish a security context. > > Right. That could use some clarification. > > * I don't understand the note. I think it says: This latter behaviour > > is sensible, since to allow security context establishment to succeed > > in this case would be problematic absent any indication of whether > > channel binding was used. Maybe? But I note that's also what this > > document recommends later in =C2=A73, so I suspect I'm wrong. > > Nico, do you have comments here? > > > * There is no such indication in GSS-APIv2u1. > > Yes - specifying the behavior here is (in my view) more important than > which way we specify it. > > > b) Empty Contexts > > > > It's a mystery to me why this is in this document. The rationale isn't > > explained at all. It might be that this is obvious to anyone > > indoctrinated into the dark art of GSS-API, which I'm certainly > > not. But it's first mentioned in =C2=A71.1 as if it were a necessary > > extension for addressing the problems described in =C2=A71. Is > > GSS_Set_context_flags() always to be called with an empty context? > > Good point. It's valid to call with a non-empty context as I understand > (maybe Nico can speak more on this?), but the important attribute is > ret_flags_understood, which there isn't currently a way to convey. And > then just doing it this particular way is based on how the Java bindings > work (1.1). > > How about this for text in 1.1: > > The design for signalling application flag support and empty > contexts is based on the Java Bindings of the GSS-API [RFC5653]. We > introduce a new function GSS_Set_context_flags() for applications to > instruct the GSSAPI implementation what flags they understand. > However, since the understood flags information needs to be present > before GSS_Init/Accept_sec_context() are called, we also introduce a > notion of empty contexts, and begin introduction of additional > context inquiry and mutation functions, which eventually will also > allow for simplified stepping to replace the > GSS_Init/Accept_sec_context() loop. > > Yes, that makes sense. > > c) Typographical errors > > > > * =C2=A71, Page 2, "provides provides" (as noted before). > > * =C2=A73, Page 7, "This strong sugestion" > > Agreed, will fix. > > > Further notes: > > > > I'm still confused about the outcome where the Initiator supports > > channel bindings but does not support the flag, and the Acceptor does > > not support channel bindings. In SCRAM, this case is special, and the > > Initiator ends up passing a channel binding essentially saying it > > could have done it if you'd asked. This allows an Acceptor to > > determine if a downgrade attack were in effect or not. I have no clue > > if this is common in GSS-API. > > Interesting. This doesn't sound like the kind of idiom we have > elsewhere in GSSAPI (not that that's necessarily a bad thing) > > Interesting - the channel bindings are transferred in SCRAM within the GS2 prefix (or header). I was expecting this case to be common. Alexey Melnikov or others might remember more detail about how that behaviour came about. > > In any case, if an Initiator is unable to know if the channel bindings > > were used or not, I agree with the initial assessment that this is > > problematic. On that basis, I'm uncomfortable with the suggestion > > that an Acceptor SHOULD ignore the channel bindings and continue > > anyway - but there are clear trade offs between interoperability and > > security here. > > > > I would therefore suggest this recommendation is downgraded to OPTIONAL > > (ie, a MAY), and the pros and cons spelt out clearly. > > We're talking about the third bullet in section 3, right? > > Yes, that's the one. > Whenever the initiator application has a) provided channel bindings > to GSS_Init_sec_context(), and b) not indicated support for the > ret_channel_bound_flag flag, then the mechanism SHOULD NOT fail to > establish a security context just because the acceptor failed to > provide channel bindings data. This strong sugestion is for > interoperability purposes, and reflects actual implementations that > have been deployed. > > The difference between SHOULD NOT / MAY NOT isn't particularly important > to me; Nico, do you have feelings in this regard? Dave. --000000000000506adc0581f5b810 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, 15 Feb 2019 at 19:39, Robbie = Harwood <rharwood@redhat.com&= gt; wrote:
Dave = Cridland <dave@cr= idland.net> writes:

> Hi all,
>
> Robbie asked me to look over the aforementioned draft, and so I did, > and sent him the notes below. You'll be able to readily tell that = I
> don't know GSS-API from a bar of soap, but I hope they're usef= ul
> nonetheless.

Thanks Dave!

> a) General comment - I'm a native English speaker, and I find pars= ing
> the double-negative "not when the initiator provides none" i= ncredibly
> hard. Is this necessary phrasing, or could this be changed to be a bit=
> more readable?
>
> For example, at the beginning of page 2:
>
>=C2=A0 =C2=A0 However, GSS-APIv2u1 [RFC2743
> <https://tools.ietf.org/html/rfc2743>] does not sp= ecify channel
> binding
>=C2=A0 =C2=A0 behavior when only one party provides provides none.In pr= actice,
>=C2=A0 =C2=A0 some mechanisms (such as Kerberos [RFC4121
> <https://tools.ietf.org/html/rfc4121>]) ignore cha= nnel bindings
>=C2=A0 =C2=A0 when the acceptor provides none, but not when the initiat= or provides
>=C2=A0 =C2=A0 none.=C2=A0 Note that it would be useless to allow securi= ty context
>=C2=A0 =C2=A0 establishment to succeed when the initiator does not prov= ide channel
>=C2=A0 =C2=A0 bindings but the acceptor does, at least as long as there= 's no
>=C2=A0 =C2=A0 outward indication of whether channel binding was used!= =C2=A0 Since the
>=C2=A0 =C2=A0 GSS-APIv2u1 does not provide any such indication, this do= cument
>=C2=A0 =C2=A0 corrects that flaw.
>
>
> So, I understand from this:
> * There is undefined behaviour when only one party supports channel > binding. I think. Note typo in the first sentence.

Yes.=C2=A0 Suggested first sentence language:

=C2=A0 =C2=A0 However, GSS-APIv2u1 [RFC2743] does not specify channel bindi= ng
=C2=A0 =C2=A0 behavior when only one party provides them.


That works.
=C2=A0
> * In practice, if an acceptor does not provide a channel binding, some=
> mechanisms ignore channel bindings entirely, such as Kerberos.

Yes.=C2=A0 In general it seems like the phrase "provides none" is= confusing -
is that right?=C2=A0 How do you feel about replacing it with language more<= br> like "when only provided by one party"?


I think "provides none" is c= onfusing - it's not a natural English formation. "when only provid= ed by one party" etc seem more understandable to me.
=C2=A0<= /div>
> * Conversely, if the initiator does not provide channel bindings, but<= br> > the acceptor does, channel bindings are typically not ignored. I have<= br> > no idea what this means in practice - does authentication fail? I get<= br> > that impression from the later paragraphs.

Yes - per section 3, the acceptor fails to establish a security context.

Right. That could use some clarificati= on.
=C2=A0
> * I don't understand the note. I think it says: This latter behavi= our
> is sensible, since to allow security context establishment to succeed<= br> > in this case would be problematic absent any indication of whether
> channel binding was used. Maybe? But I note that's also what this<= br> > document recommends later in =C2=A73, so I suspect I'm wrong.

Nico, do you have comments here?

> * There is no such indication in GSS-APIv2u1.

Yes - specifying the behavior here is (in my view) more important than
which way we specify it.

> b) Empty Contexts
>
> It's a mystery to me why this is in this document. The rationale i= sn't
> explained at all. It might be that this is obvious to anyone
> indoctrinated into the dark art of GSS-API, which I'm certainly > not. But it's first mentioned in =C2=A71.1 as if it were a necessa= ry
> extension for addressing the problems described in =C2=A71. Is
> GSS_Set_context_flags() always to be called with an empty context?

Good point.=C2=A0 It's valid to call with a non-empty context as I unde= rstand
(maybe Nico can speak more on this?), but the important attribute is
ret_flags_understood, which there isn't currently a way to convey.=C2= =A0 And
then just doing it this particular way is based on how the Java bindings work (1.1).

How about this for text in 1.1:

=C2=A0 =C2=A0 The design for signalling application flag support and empty<= br> =C2=A0 =C2=A0 contexts is based on the Java Bindings of the GSS-API [RFC565= 3].=C2=A0 We
=C2=A0 =C2=A0 introduce a new function GSS_Set_context_flags() for applicat= ions to
=C2=A0 =C2=A0 instruct the GSSAPI implementation what flags they understand= .
=C2=A0 =C2=A0 However, since the understood flags information needs to be p= resent
=C2=A0 =C2=A0 before GSS_Init/Accept_sec_context() are called, we also intr= oduce a
=C2=A0 =C2=A0 notion of empty contexts, and begin introduction of additiona= l
=C2=A0 =C2=A0 context inquiry and mutation functions, which eventually will= also
=C2=A0 =C2=A0 allow for simplified stepping to replace the
=C2=A0 =C2=A0 GSS_Init/Accept_sec_context() loop.


Yes, that makes sense.
=C2= =A0
> c) Typographical errors
>
> * =C2=A71, Page 2, "provides provides" (as noted before). > * =C2=A73, Page 7, "This strong sugestion"

Agreed, will fix.

> Further notes:
>
> I'm still confused about the outcome where the Initiator supports<= br> > channel bindings but does not support the flag, and the Acceptor does<= br> > not support channel bindings. In SCRAM, this case is special, and the<= br> > Initiator ends up passing a channel binding essentially saying it
> could have done it if you'd asked. This allows an Acceptor to
> determine if a downgrade attack were in effect or not. I have no clue<= br> > if this is common in GSS-API.

Interesting.=C2=A0 This doesn't sound like the kind of idiom we have elsewhere in GSSAPI (not that that's necessarily a bad thing)


Interesting - the channel bindings are= transferred in SCRAM within the GS2 prefix (or header). I was expecting th= is case to be common. Alexey Melnikov or others might remember more detail = about how that behaviour came about.
=C2=A0
> In any case, if an Initiator is unable to know if the channel bindings=
> were used or not, I agree with the initial assessment that this is
> problematic.=C2=A0 On that basis, I'm uncomfortable with the sugge= stion
> that an Acceptor SHOULD ignore the channel bindings and continue
> anyway - but there are clear trade offs between interoperability and > security here.
>
> I would therefore suggest this recommendation is downgraded to OPTIONA= L
> (ie, a MAY), and the pros and cons spelt out clearly.

We're talking about the third bullet in section 3, right?


Yes, that's the one.
=C2= =A0
=C2=A0 =C2=A0 Whenever the initiator application has a) provided channel bi= ndings
=C2=A0 =C2=A0 to GSS_Init_sec_context(), and b) not indicated support for t= he
=C2=A0 =C2=A0 ret_channel_bound_flag flag, then the mechanism SHOULD NOT fa= il to
=C2=A0 =C2=A0 establish a security context just because the acceptor failed= to
=C2=A0 =C2=A0 provide channel bindings data.=C2=A0 This strong sugestion is= for
=C2=A0 =C2=A0 interoperability purposes, and reflects actual implementation= s that
=C2=A0 =C2=A0 have been deployed.

The difference between SHOULD NOT / MAY NOT isn't particularly importan= t
to me; Nico, do you have feelings in this regard?

Dave.=C2=A0
--000000000000506adc0581f5b810-- From nobody Sun Feb 17 12:21:43 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 355FE128CB7; Sun, 17 Feb 2019 12:21:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Scott Bradner 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.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155043488911.4083.7977373920397028733@ietfa.amsl.com> Date: Sun, 17 Feb 2019 12:21:29 -0800 Archived-At: Subject: [kitten] Opsdir last call review of draft-ietf-kitten-pkinit-alg-agility-04 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: Sun, 17 Feb 2019 20:21:29 -0000 Reviewer: Scott Bradner Review result: Has Nits This is an OPS-DIR review of PKINIT Algorithm Agility (draft-ietf-kitten-pkinit-alg-agility). This ID updates PKINIT following the guidelines in BCP 201 to make it algorithm agile and to expose acceptable algorithms. This is a very well written clear document. I do not find any operational issues with the document except that the document could use a section on interoperability (old server-new client, new server-old client). There are a few words about the topic deep in section 6 about the supportedKDFs field but I do not see a general discussion or a discussion about the kdf field. The text about the supportedKDFs field could be moved to a new section and each of the old/new combinations could be addressed. I see this as an operational issue because compatibility issues are a frequent source of operational headaches. From nobody Sun Feb 17 22:13:03 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 DE83E124B0C; Sun, 17 Feb 2019 22:12:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Takeshi Takahashi 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.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155047036985.3948.13609799438850064569@ietfa.amsl.com> Date: Sun, 17 Feb 2019 22:12:49 -0800 Archived-At: Subject: [kitten] Secdir last call review of draft-ietf-kitten-pkinit-alg-agility-04 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: Mon, 18 Feb 2019 06:12:50 -0000 Reviewer: Takeshi Takahashi Review result: Ready I do not see any serious issues on this draft and enjoyed reading it. I have only minor questions for the purpose of deepening my understanding of the draft. 1. In section 5, regarding the The TD-CERT-DIGEST-ALGORITHMS-Data message, who embed the rejectedAlgorithm field? If it will be the KDC, why does the KDC need to fill and distribute this information to the others? 2. In section 8 (security consideration), it is stated that "to do otherwise allows an active attacker to perform a downgrade attack". In my understanding of the draft, arbitrary algorithm could be used (if the negotiation reaches agreements). I wonder if there is any mechanism that discourages the negotiation of using insecure algorithms. For instance, the list of algorithms that must be treated with care could be listed somewhere? Thank you, and kind regards, Take From nobody Mon Feb 18 13:29: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 A240D13103B for ; Mon, 18 Feb 2019 13:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.253 X-Spam-Level: X-Spam-Status: No, score=-0.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_SOFTFAIL=0.665] 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 a2sWETkf2i-T for ; Mon, 18 Feb 2019 13:29:43 -0800 (PST) Received: from mail.suchdamage.org (ec2-52-9-186-167.us-west-1.compute.amazonaws.com [52.9.186.167]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F1C6131010 for ; Mon, 18 Feb 2019 13:29:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.suchdamage.org (Postfix) with ESMTP id 3C1E52168A for ; Mon, 18 Feb 2019 16:29:42 -0500 (EST) Received: from mail.suchdamage.org ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXQN8FJuemb3 for ; Mon, 18 Feb 2019 16:29:41 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (c-24-91-242-186.hsd1.nh.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 for ; Mon, 18 Feb 2019 16:29:41 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4CB3FC0944; Mon, 18 Feb 2019 16:29:40 -0500 (EST) From: Sam Hartman To: kitten@ietf.org Date: Mon, 18 Feb 2019 16:29:34 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: [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, 18 Feb 2019 21:29:46 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I've reviewed this document at the request of one of the authors, and here are my comments: 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. 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. 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. 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. 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. 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. * 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. * I think it does not consider behavior when mutual authentication is not requested. * 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. * 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. Here are my specific comments: >Note that it would be useless to allow security context > establishment to succeed when the initiator does not provide channel > bindings but the acceptor does, at least as long as there's no > outward indication of whether channel binding was used! An exclamation in an IETF document is a good sign that you're letting your emotions get ahead of your technical content and perhaps you should take a step back. I think the above quote is a good example. You don't get MITM protection if the initiator provides channel binding and the acceptor does, but it can be useful none-the-less. Assuming that an attacker cannot convert a context token that has channel bindings into one that does not, and initiators know acceptors are providing channel bindings, then initiators know that if they provide channel bindings then the channel bindings are validated. That can provide you defense in depth, for example, binding channels to a TLS channel binding in applications where you also validate the PKI and have good trust anchors. It cannot be sufficient alone to provide MITM defense. However, additional layers of defense (provided they do not trigger false negatives) are valuable in security. Please rephrase to focus on the characteristics of the system rather than judgments of those characteristics. > o Whenever both the initiator and acceptor have provided > input_channel_bindings to GSS_Init/Accept_sec_context() and the > channel bindings do not match, then the mechanism MUST fail to > establish a security context token. (This is a restatement of an > existing requirement in the base specification.) Actually, as best I can tell, RFC 2743section 1.1.6 disagrees with this. It looks in RFC 2743 like channel bindings are optional for a mechanism to use. I think it's reasonable that if a mechanism supports channel bindings, then if both the initiator and acceptor provide channel bindings they must validate for context establishment to succeed. > o Whenever the acceptor application has a) provided channel bindings > to GSS_Accept_sec_context(), and b) not indicated support for the > ret_channel_bound_flag flag, then the mechanism MUST fail to > establish a security context if the initiator did not provide > channel bindings data. This requirement is critical for security > purposes, to make applications predating this document secure, and > this requirement reflects actual implementations as deployed. Actually, this behavior is inconsistent with RFC 7055 section 5.6.2 and with the Moonshot implementation of the ABFAB GSS-API mechanism. In that mechanism, if the initiator provides null channel bindings, the acceptor channel bindings are always ignored. I'm not seeing the security issue here. If you are using channel bindings as a MITM defense rather than as an additional layer of security, you need to do something like SASL does and have a plus and minus varient of your protocol and always pass in channel bindings. There's also what I think is a real operational issue here. You may not be able to know what your channel bindings are on an acceptor. Depending on whether you are behind a TLS accelerator, reverse proxy or the like, it may affect your ability to know your channel bindings. I > o Whenever the application has a) provided channel bindings to > GSS_Init_sec_context() or GSS_Accept_sec_context(), and b) > indicated support for the ret_channel_bound_flag flag, then the > mechanism SHOULD NOT fail to establish a security context just > because the peer did not provide channel bindings data. The > mechanism MUST output the ret_channel_bound_flag if both peers > provided the same input_channel_bindings to GSS_Init_sec_context() > and GSS_Accept_sec_context(). The mechanism MUST NOT output the > ret_channel_bound_flag if either (or both) peer did not provide > input_channel_bindings to GSS_Init/Accept_sec_context(). This > requirement restores the original base GSS-API specified behavior, > with the addition of the ret_channel_bound_flag flag. I think we need to consider the transition period here. What happens when you have a new initiator talking to an old acceptor or vice versa.Are you planning on introducing new over-the-wire signaling so that an acceptor can say something like "I'm setting up your context, but your channel binding didn't verify?" For example in RFC 7055, the channel binding data is sent as a checksum from initiator to acceptor. The acceptor either sends back a final token or sends back an error depending on whether it accepts the bindings. How, without protocol changes would we meet this requirement. Similarly, I think Kerberos works the same way in the mutual authentication case. In the non mutual authentication case, I don't think the initiator even learns whether the acceptor validated the channel bindings. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE9Li3nMNy++OFgPTCQe7SUh/WssoFAlxrI74ACgkQQe7SUh/W sspG4wf/S9/QCjMosLzigs4BqnIk6QYNy/eI/9J24uOYZBl+gAei6yT+mB6JssbV 8nFwxEqjVYYTitgGQgwSvcPVu4ToJ4xfMeLMNTL+XUtcsH6yRoo7xh6dItPkovIX 8MostIUeWsSyz6ED1Vo3rVou+/pUxqB4xEvb+Npz+sIn2oqvu//Nlc9Q30W1hQu1 6jsuF/dOqqvus2FSo8N1kh81O0CQeYNyWpicCZVCy7M5Y6aHPVVwIvbE7bKuXB8C jYPK7xKu5Is2H5beIrc7pgW3nif6KG2EfCY8Co6ki0viJUERI+iG/u9PAYJ+Rbxw hsuxkVBn+DHRnysznAzmPA216n4kog== =W4An -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Feb 18 13:39: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 011BB13104B for ; Mon, 18 Feb 2019 13:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.253 X-Spam-Level: X-Spam-Status: No, score=-0.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_SOFTFAIL=0.665] 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 f7e91fp2KF7q for ; Mon, 18 Feb 2019 13:39:15 -0800 (PST) Received: from mail.suchdamage.org (ec2-52-9-186-167.us-west-1.compute.amazonaws.com [52.9.186.167]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0E28131051 for ; Mon, 18 Feb 2019 13:39:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.suchdamage.org (Postfix) with ESMTP id 3C3422BCF5; Mon, 18 Feb 2019 16:39:14 -0500 (EST) Received: from mail.suchdamage.org ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jC623K0G6zaa; Mon, 18 Feb 2019 16:39:13 -0500 (EST) 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; Mon, 18 Feb 2019 16:39:13 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4A9CFC0944; Mon, 18 Feb 2019 16:39:12 -0500 (EST) From: Sam Hartman To: Sam Hartman Cc: kitten@ietf.org References: Date: Mon, 18 Feb 2019 16:39:12 -0500 In-Reply-To: (Sam Hartman's message of "Mon, 18 Feb 2019 16:29:34 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" 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, 18 Feb 2019 21:39:17 -0000 --=-=-= Content-Type: text/plain >>>>> "Sam" == Sam Hartman writes: nnel >> bindings to GSS_Accept_sec_context(), and b) not indicated >> support for the ret_channel_bound_flag flag, then the mechanism >> MUST fail to establish a security context if the initiator did >> not provide channel bindings data. This requirement is critical >> for security purposes, to make applications predating this >> document secure, and this requirement reflects actual >> implementations as deployed. Sam> Actually, this behavior is inconsistent with RFC 7055 section Sam> 5.6.2 and with the Moonshot implementation of the ABFAB GSS-API Sam> mechanism. In that mechanism, if the initiator provides null Sam> channel bindings, the acceptor channel bindings are always Sam> ignored. I'm not seeing the security issue here. If you are Sam> using channel bindings as a MITM defense rather than as an Sam> additional layer of security, you need to do something like Sam> SASL does and have a plus and minus varient of your protocol Sam> and always pass in channel bindings. Sam> There's also what I think is a real operational issue here. Sam> You may not be able to know what your channel bindings are on Sam> an acceptor. Depending on whether you are behind a TLS Sam> accelerator, reverse proxy or the like, it may affect your Sam> ability to know your channel bindings. I meant to go back and revise my review before sending. I think it's something worth fixing that Kerberos and ABFAB have inconsistent behavior here, and I do think it's worth standardizing. I think we're in a good position. If we were to decide to relax the behavior we'd be changing Kerberos in a manner where all authentications that succeed today would continue to succeed. Kerberos is much much much more widely deployed than ABFAB. If we were to decide to make the behavior as strict as described in this draft, then we'd be potentially breaking valid uses of ABFAB, but I think the ABFAB deployment is small enough that it is reasonable to do that. However, I think that the decision as to what to do should be based on analysis of applications where one side uses channel bindings and the other does not. Since I'm not actually aware of any significant applications that do that, I'll hold off until my previous question on that issue is answered before forming my opinion on the correct behavior. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE9Li3nMNy++OFgPTCQe7SUh/WssoFAlxrJgAACgkQQe7SUh/W sso+YQgAu1IFycuaMVKgjLxhIobOsZmtOaYWDV7azb3oyqZiiS4t4APrWv/N3STm xvp1ddtaVV8bkgeCDZjOzb1Gjd1b0d7tpv0+nkThvWhDQ9wv+dcgdScHaJoD+b1G VYcQ9lzG4rJH+T+FJ5a5L203q2H3H9/Xe3fxua2bJQdgNUL4FO+v5zCo1UjeJq68 LWXD5+v/jkNq8PNETxVfnizJ8ORK5GcIGGmmiIJWejXand97gih7kDswpg4BHsyF Np/2qxo6qr9oh/3eqlf5DsgA7Tf4z7t4oPpHQUA/Frv+9xwAxSnWTCNa8/7b3Fw+ NC3E480F68EBK9cQgfALgJzbBSP9dg== =ZhzG -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Feb 19 04:29:14 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 74BE4130ED4 for ; Tue, 19 Feb 2019 04:29:12 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=padl.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 d-HrR0egbhNV for ; Tue, 19 Feb 2019 04:29:10 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (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 74EB9130ECA for ; Tue, 19 Feb 2019 04:29:10 -0800 (PST) Received: by us.padl.com with ESMTP id x1JCSna1027563; Tue, 19 Feb 2019 12:28:53 GMT DKIM-Filter: OpenDKIM Filter v2.11.0 us.padl.com x1JCSna1027563 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=padl.com; s=default; t=1550579334; bh=bIvpZYTjZ57rLSbwyDNLDGYh6ry8yE+fnEGcfasuE38=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=lMa8LJXoljY7pKsb8VbH+LZ0dROqgIdmVot7W+UBDRFgcXR9T0HG4+IjpXXQsqsh8 ReGePozuhpRMlXywGRLluAZx+0ZVYz7ne9S80SJA750c7yE6+lqlVE1Z/q5OlR3z+O 4/8o9c8KBFBSfX4Dh4rkWsc7Jxt+b9UewT49ZemomLWkfIdApgJbvDWnK/7VoDDLtv YVmWWS7QWUiCFTAIonMmdtDLy3Dldko2Dq88/9jGNYLKila6pfJfiXTyW2+m52eRpX GbEsPbOcOkUp7ItULbEpX+2HpBlHCjzDhZ0NC1KBBAqgYg2DwL/ZfGMV8aAVwf5lz1 YuO5N+N7GvPfQ== From: Luke Howard Message-Id: <89D5C410-8D5A-4699-B489-953F4FE65F87@padl.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_61A5A4E6-C141-4352-931D-B5C5E0F09FB3" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 19 Feb 2019 13:29:03 +0100 In-Reply-To: Cc: "kitten@ietf.org" To: Sam Hartman References: X-Mailer: Apple Mail (2.3445.9.1) 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: Tue, 19 Feb 2019 12:29:12 -0000 --Apple-Mail=_61A5A4E6-C141-4352-931D-B5C5E0F09FB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 18 Feb 2019, at 10:29 pm, Sam Hartman = wrote: >=20 > * 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. gss_create_sec_context() and gss_set_context_flags() could be subsumed = into gss_set_sec_context_option() which is supported by both Heimdal and = MIT. But perhaps not as easy to use for the caller. --Apple-Mail=_61A5A4E6-C141-4352-931D-B5C5E0F09FB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = 18 Feb 2019, at 10:29 pm, Sam Hartman <hartmans-ietf@mit.edu> wrote:

* 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.

gss_create_sec_context() and gss_set_context_flags() = could be subsumed into gss_set_sec_context_option() which is = supported by both Heimdal and MIT. But perhaps not as easy to use for = the caller.
= --Apple-Mail=_61A5A4E6-C141-4352-931D-B5C5E0F09FB3-- From nobody Wed Feb 20 12:56:54 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 AE5CB12950A; Wed, 20 Feb 2019 12:56:37 -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 7yuLpdZ5nydu; Wed, 20 Feb 2019 12:56:35 -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 570A912D4E7; Wed, 20 Feb 2019 12:56:35 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 66682C057F2F; Wed, 20 Feb 2019 20:47:52 +0000 (UTC) Received: from localhost (ovpn-112-77.rdu2.redhat.com [10.10.112.77]) by smtp.corp.redhat.com (Postfix) with ESMTP id 180041001DC1; Wed, 20 Feb 2019 20:47:51 +0000 (UTC) From: Robbie Harwood To: Takeshi Takahashi , secdir@ietf.org Cc: ietf@ietf.org, kitten@ietf.org, draft-ietf-kitten-pkinit-alg-agility.all@ietf.org In-Reply-To: <155047036985.3948.13609799438850064569@ietfa.amsl.com> References: <155047036985.3948.13609799438850064569@ietfa.amsl.com> Date: Wed, 20 Feb 2019 15:47:49 -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.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 20 Feb 2019 20:47:52 +0000 (UTC) Archived-At: Subject: Re: [kitten] Secdir last call review of draft-ietf-kitten-pkinit-alg-agility-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, 20 Feb 2019 20:56:38 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Takeshi Takahashi writes: > Reviewer: Takeshi Takahashi > Review result: Ready > > I do not see any serious issues on this draft and enjoyed reading it. > I have only minor questions for the purpose of deepening my > understanding of the draft. Awesome, thanks for taking a look! Let me see if I can help. > 1. In section 5, regarding the The TD-CERT-DIGEST-ALGORITHMS-Data > message, who embed the rejectedAlgorithm field? If it will be the KDC, > why does the KDC need to fill and distribute this information to the > others? It has to be the KDC. I believe the purpose of sending TD-CERT-DIGEST-ALGORITHMS-DATA is to enable clients that have multiple certificates to retry, to enable debugging without KDC access, and worst-case to allow the user to request re-issuance of the certificate in question. rfc4556 section 3.2.2 (PKINIT's specification for how to handle client requests) states: If the digest algorithm used in generating the CA signature for the public key in any certificate of the request is not acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120] message with the code KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED. The accompanying e-data MUST be encoded in TYPED-DATA, although none is defined at this point. The important part here is that it applies to *any* certificate in the request. Sending the rejectedAlgorithm helps figure out which cert is problematic. There are other ways this could have been accomplished, but that ship has sailed. (Finally, the KDC doesn't technically "need" to send this structure; if it wishes for some reason to be mysterious, the draft specifies that the KDC "can OPTIONALLY send a list of digest algorithms".) > 2. In section 8 (security consideration), it is stated that "to do > otherwise allows an active attacker to perform a downgrade attack". In > my understanding of the draft, arbitrary algorithm could be used (if > the negotiation reaches agreements). I wonder if there is any > mechanism that discourages the negotiation of using insecure > algorithms. For instance, the list of algorithms that must be treated > with care could be listed somewhere? The security properties we're counting on from underling algorithms (like SHA1) here are pretty normal. Personally, I don't think we should be tracking algorithm security for Kerberos separately than from the rest of the crypto ecosystem - for instance, sha1 weakening affects TLS and everyone else just as it does us. That said, there have been two RFCs so far about removing algorithms from Kerberos: 6649 (1DES and export-strength RC4) and 8429 (3DES and the rest of RC4). Adoption of these is difficult, however, since some sites require interop with older setups (such as Windows Server 2003) that don't support AES. The result is that Kerberos implementations tend to enable by default only a subset of the algorithms they fully support. Making the tradeoff between security and interoperability is left as a policy decision. On the management side, Linux distros have been working to tie all these different configuration knobs together in one place. I'm sure there are others, but in Fedora we use the crypto-policies [1] project to handle weakenings/deprecations of various algorithms across the software in the distribution. Thanks, =2D-Robbie 1: https://gitlab.com/redhat-crypto/fedora-crypto-policies --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAlxtvPUACgkQJTL5F2qV pEJw0Q//aZjr+KbQ876poRK6gknx9zOFALto1eX6EBBww9Si8BiLrkaI9WClWZdi 79Gg01oUXbDfDZyy/DvQiu70KRMGDqsLSttHfdxZOg4x4l9un4185c0FRDCNat3I RoUGpSxmuOQTNNjDTffJQgQ/tq3U38dDqA6E/VXjmyrW0JM404jHeNx7r73kGg9r tbp68hhuBbY/zOzKRvX9MEFfDnoMx0MhYjWlc3/XtPcwmxbHHS4gge8VH7CGrERm 3h5a+WOCkscUZgAom2hRZd0uJ65Ufrv3K9WgJv25XvNoP+PLd5eJ84OH/3uHd9DP gfVvopbR4AhGSexgbrG2/FPXuv59SdRe3MaDDBvx2yfRa7dcZHJR5AfRNxBVphcP Tq8PEZ0x2Py8rdu9kO56D5xqJollhmBZn4n/GYGAmZS5TanLhYvdGYrywVQTKNqj LqhFTzwCoWa57PPDu/P8DSBvY/mYuLTCe6gm+BpLta6QYmDkpRnfT41Wgbs6wCe8 dvScdFgCAwbz1ZC2LdEnyiYmcxDYV60LHreCje4MGgRf2Jbb0LzRxOKO7kiubb/+ aoSW6pIzNTFHUTcdl/ziO+mpTKcn1EVn8nz9HQly7EI8MVQaJkOWHATBsAOb85Gc Nv0CYIlGlAms/Ho0Eml94dwGZN5M1o4JkAGRNIVclf5m0idBq0w= =Xufk -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Feb 22 06:26: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 37A0D128B14; Fri, 22 Feb 2019 06:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 7oRP3ImVl6L7; Fri, 22 Feb 2019 06:26:15 -0800 (PST) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 9964E1200D7; Fri, 22 Feb 2019 06:26:15 -0800 (PST) Received: by mail-qt1-x82b.google.com with SMTP id o6so2634809qtk.6; Fri, 22 Feb 2019 06:26:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:references:to:date; bh=u6nnyJZvwX6d090ZcsLyhBwCeq/u+T+EbaPs8Z2tW7s=; b=oeLGI+gnc9BlyuYZHowTEw86AQs7dui0HRT0glGYG3xcDJG94ZYxMWvY8R1jqZqjrw a0310arntlzXtE6uGfM/U6PauaBaF84Ylf1AoHRjiEb4SXgXWmW1Yt2bkZkS9aE1Sey4 SYnib47Z+eJSYlCzHlAJ3k4geh0CWTpuvLshi+l34b11SN3JO8S5Kej1T54e40e0i4gk UrNIhZzWsJImK+pYm4hQBNrIzJg0PS+LReGoiRpVgqMFcnpkTIz4FgRzosJwx9EIK4FI C51x+NVyu3lhQ+mlKwJMtZ11MNwXnt3YwzOFUL7tt9zGaCbzpgInPNfmKEQNN0itZx3y xZpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=u6nnyJZvwX6d090ZcsLyhBwCeq/u+T+EbaPs8Z2tW7s=; b=g0N4Zi9/85G2RcZkLbp2vIlwgYb+YErAh3myM+RNA/+pJNKaJhhhvNBcuE7UDVlKgB ZrpgiFUaj5kULZzlf4R/tXihkZdiQKumSoFuM0EVTVI4cg6MT4p8+lWe0u5wseaHNvzT Cu6W6eR0RrSikOyN0kofKmVLgKqTF8vovQhUlubWYHFr5vqpCNeQohMUtFCPxLl683nR IFgPg4hPfd/SdNL9j+CH8CrMnl1bAqYxTPeCTE8GpoPavvZFA1DEZvZYrCemafJG727f FW6kfu0bvGjWwTzO0rJDqpCbgyi1YmftAdvhzvgH2pVhp7OBls0FBErMCIB5WMbTzh64 n/4A== X-Gm-Message-State: AHQUAuZTNx9sT39cJrKRvc0CVBIT/HeCwGG9MwKgAY6zIU8I8L5m7RzN qzK9XJ4WM6i6q2E/4Vk8w0Wry51S X-Google-Smtp-Source: AHgI3IbTw7grciyDTXLm4WhT1Eo0HN4pSJuY2eUGCweIf1se4uCWgZFjJ6MEjFLWOWLCVYrXD1cMYg== X-Received: by 2002:ac8:1c4a:: with SMTP id j10mr3330227qtk.37.1550845574327; Fri, 22 Feb 2019 06:26:14 -0800 (PST) Received: from golem.sobco.com (golem.sobco.com. [136.248.127.162]) by smtp.gmail.com with ESMTPSA id m42sm966194qtb.63.2019.02.22.06.26.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Feb 2019 06:26:13 -0800 (PST) From: Scott Bradner Content-Type: multipart/alternative; boundary="Apple-Mail=_843238EB-5372-434B-90EB-D943382A314D" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <9146506F-8096-4C6B-BBA6-491E0A55EC0F@gmail.com> References: <155043488911.4083.7977373920397028733@ietfa.amsl.com> To: draft-ietf-kitten-pkinit-alg-agility.all@ietf.org, kitten@ietf.org Date: Fri, 22 Feb 2019 09:26:11 -0500 X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [kitten] resend: [OPS-DIR] Opsdir last call review of draft-ietf-kitten-pkinit-alg-agility-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, 22 Feb 2019 14:26:18 -0000 --Apple-Mail=_843238EB-5372-434B-90EB-D943382A314D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am resending this because the review tool seems to have failed to = properly distribute it Scott > Begin forwarded message: >=20 > From: Scott Bradner > Subject: [OPS-DIR] Opsdir last call review of = draft-ietf-kitten-pkinit-alg-agility-04 > Date: February 17, 2019 at 3:21:29 PM EST > To: > Cc: kitten@ietf.org, ietf@ietf.org, = draft-ietf-kitten-pkinit-alg-agility.all@ietf.org >=20 > Reviewer: Scott Bradner > Review result: Has Nits >=20 > This is an OPS-DIR review of PKINIT Algorithm Agility > (draft-ietf-kitten-pkinit-alg-agility). This ID updates PKINIT = following the > guidelines in BCP 201 to make it algorithm agile and to expose = acceptable > algorithms. >=20 > This is a very well written clear document. I do not find any = operational > issues with the document except that the document could use a section = on > interoperability (old server-new client, new server-old client). >=20 > There are a few words about the topic deep in section 6 about the = supportedKDFs > field but I do not see a general discussion or a discussion about the = kdf > field. The text about the supportedKDFs field could be moved to a new = section > and each of the old/new combinations could be addressed. I see this = as an > operational issue because compatibility issues are a frequent source = of > operational headaches. >=20 >=20 > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir --Apple-Mail=_843238EB-5372-434B-90EB-D943382A314D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = am resending this because the review tool seems to have failed to = properly distribute it

Scott

Begin forwarded = message:

From: = Scott Bradner <sob@sobco.com>
Subject: = [OPS-DIR] Opsdir = last call review of draft-ietf-kitten-pkinit-alg-agility-04
Date: = February 17, 2019 at 3:21:29 PM = EST
To: = <ops-dir@ietf.org>
Cc: = kitten@ietf.org, ietf@ietf.org, draft-ietf-kitten-pkinit-alg-agility.all@ietf.org

Reviewer: Scott Bradner
Review result: Has = Nits

This is an OPS-DIR review of PKINIT = Algorithm Agility
(draft-ietf-kitten-pkinit-alg-agility). =  This ID updates PKINIT following the
guidelines in = BCP 201 to make it algorithm agile and to expose acceptable
algorithms.

This is a very well = written clear document.  I do not find any operational
issues with the document except that the document could use a = section on
interoperability (old server-new client, new = server-old client).

There are a few words = about the topic deep in section 6 about the supportedKDFs
field but I do not see a general discussion or a discussion = about the kdf
field. The text about the supportedKDFs = field could be moved to a new section
and each of the = old/new combinations could be addressed.  I see this as an
operational issue because compatibility issues are a frequent = source of
operational headaches.


_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir

= --Apple-Mail=_843238EB-5372-434B-90EB-D943382A314D-- From nobody Fri Feb 22 06:29:01 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 381A3130FD1; Fri, 22 Feb 2019 06:28:55 -0800 (PST) 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 ktgnNrra0RBH; Fri, 22 Feb 2019 06:28:52 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-eopbgr790133.outbound.protection.outlook.com [40.107.79.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90771130EF2; Fri, 22 Feb 2019 06:28:48 -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=Del22jvC5tYvpAW5IcYTNjb6RvCaj+QBxKbfLsWzpeE=; b=T7Eqcj1KYCu6CcSdaCyOaTGormd95N+aAAJLT540g2AtgJpSB0PQRVKdMFx3snbNG4W4OFHn52Qjphp7qS87VrpHnZ6aBqB+7+TpU1X0gwD/ZCpysH6D3BOYDHioG9p34YYyfpRrs8OdI+cqvC8rM+jmeiPQosWk0fmDVWLF7M8= Received: from DM5PR0102CA0011.prod.exchangelabs.com (2603:10b6:4:9c::24) by BN6PR01MB3284.prod.exchangelabs.com (2603:10b6:404:d9::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.18; Fri, 22 Feb 2019 14:28:46 +0000 Received: from BY2NAM03FT012.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::206) by DM5PR0102CA0011.outlook.office365.com (2603:10b6:4:9c::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.14 via Frontend Transport; Fri, 22 Feb 2019 14:28:46 +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 BY2NAM03FT012.mail.protection.outlook.com (10.152.84.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13 via Frontend Transport; Fri, 22 Feb 2019 14:28:45 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1MESgC3021200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Feb 2019 09:28:44 -0500 Date: Fri, 22 Feb 2019 08:28:42 -0600 From: Benjamin Kaduk To: Scott Bradner CC: , Message-ID: <20190222142841.GW69562@kduck.mit.edu> References: <155043488911.4083.7977373920397028733@ietfa.amsl.com> <9146506F-8096-4C6B-BBA6-491E0A55EC0F@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <9146506F-8096-4C6B-BBA6-491E0A55EC0F@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(346002)(39860400002)(136003)(376002)(2980300002)(189003)(199004)(186003)(1076003)(104016004)(316002)(786003)(36906005)(16586007)(55016002)(6306002)(46406003)(336012)(6246003)(54906003)(58126008)(5660300002)(50466002)(7696005)(26005)(47776003)(8676002)(14444005)(6916009)(76176011)(246002)(106466001)(88552002)(106002)(2906002)(53416004)(4326008)(86362001)(446003)(956004)(1411001)(476003)(126002)(11346002)(229853002)(97756001)(478600001)(75432002)(486006)(966005)(33656002)(305945005)(26826003)(23726003)(8936002)(426003)(356004)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR01MB3284; 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: 3ec64317-f7fe-46ec-eb43-08d698d20dc3 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:BN6PR01MB3284; X-MS-TrafficTypeDiagnostic: BN6PR01MB3284: X-MS-Exchange-PUrlCount: 1 X-Microsoft-Exchange-Diagnostics: 1; BN6PR01MB3284; 20:v7dLj6ExVc8AVpBDMXGadMfzNF29Cvsa5T3j9y5WSeMSPwlXDwW5ZSUgIi6VGXQjleAC+FCdVWDxfITKYrxAbpI57S5oVRB3bmWNnt3b57L1ejbG3jidWo1/hw9Vu1b/7eEMycObhYxhaPPqAtyXYvy353gpXWD4YXX0WIFRZvpJbeB0i/ZX0z5qXfErBQYPF+k2kJZszf3w5G3UaW9M6LsZQZOF3Xa/nX4IvZp+Kfi/Y7wBHaSGJFP16ace8WzhMnJDvasiWgYZerwBdKQ8L7UU77vFe5KUw6IL7ATSEIrwdGbszhS4hU3dGNRvMCjZPtKJkIJcDycDqF9pKyOARxyrhpwsMfbwwqkPsAtSb8OSsf5haFX46wWVdS8ljzBhdEzi9M+LtIognhpNVV2LXt9t60vg44UgQUAPe6iToBAsvpxTmHGEqKFtu/M1r6qIQsjH+5DxUSt+GvCPokrw1ji7NgsbOefRZkV+MbRmXd0njXKvswIQ38B23uMj9cvK8YVLjqS+M3WclTLucA7307Dy5tGkVqpTrdE8wYP74WQinTKBP6JeGc7cdk04uLOQ6Elq/Th5NLBzUWpWLCE8dLQvi+LbWnsoJdSj/7+CcAQ= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 09565527D6 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN6PR01MB3284; 23:+pU+OIaIFsi3/wKBUe0mQchI75IEOPf/aG1L0lH2W?= =?us-ascii?Q?Yb0ta++avlC3TndNIs85AFSYvV9cblvQ2Es7jofH7Nlm14jQb1npNo18zgPP?= =?us-ascii?Q?AWx0qYM5+nYKHBsvMOEiTC8xIdn3hzxoOpQVFZkGLrEUEvubQHunLZqIffGc?= =?us-ascii?Q?TflAGnEpq1w9jCeWs9VlOHrkvGPbQFU1xkDhDMA/Ek2L+vUzjm0zYbWfB5NP?= =?us-ascii?Q?fd/kqk3SUq6T2pcZw8V19Gg/s9YjrtRbII4hDoXH6jV06lkrIZEgIGfyrEIm?= =?us-ascii?Q?VwjD0uh2s0rRmopBisEzw/4t+WKv6A5RcXff4LDsOulPD6Azc4C4WHAXjsl6?= =?us-ascii?Q?e9xpbgLxeKLhoGD7xv7bFK0exySWDQtF16uLrPz53ufNTQmtn3pPqkuMigYi?= =?us-ascii?Q?ESsLSmKQ6qjvbtABBHvX78+5uZsOn5U7vnw09RU5EbvjTckHCUVXbWcci4o/?= =?us-ascii?Q?DNkeGB1gEbGdfXoy2A6MDMB/y0fEU6RHYfV01WNn9OXaWQSYOkplmeLVyaT2?= =?us-ascii?Q?hv9yuRW0sFnQqFBRVV9gXkRZkBXhHViZhSvHd6er64Dc0b8H4v0OobDJWNJ2?= =?us-ascii?Q?/D5/V+GdfL4swLVQSInBhI9f2btlcheSbbWIvrJtLDaEuliB6ZyuMYY0C3p1?= =?us-ascii?Q?IfoCVW7OF6ZcAI9YWVcY0wdpX9mGMmSohZ0reP5NPwZgQr7aLIZtEVPKTEdN?= =?us-ascii?Q?Qh2WKXDar0dHrPQsExlQeIA4m2z72K21XVGj/pVG5jICxHo69u81gRDNI0jP?= =?us-ascii?Q?ZkQiGFAeEGBWKqSkecOsrIIHgVukG9ln0EwYYTIq5Rl9WxCmjzISbes41HPx?= =?us-ascii?Q?IEm1lbyU+D/ZzZzBgNU/unudUbvCNR0xHwJPcA/hstc1m2P86Tvlis148Xym?= =?us-ascii?Q?9MSrMJq0i6nuyVqqdJYaSTnTqIFkm4HsqKpCuFZxlps6fsJfQRcHavHLMC2n?= =?us-ascii?Q?GvT9+kn4KnreO67iHxB+4QB/XxpBx+VAHbyla+PVOie384rUx5MkX/6E6z2n?= =?us-ascii?Q?p02jlD0Lc7hdYBk5DpxAix7I128j31tCR9LiYT8zy+89/nD9a1M3zkPh6K6j?= =?us-ascii?Q?wStGh2dhqV3IhbhstBpG8xEb8ilFqLoiPQGsFeWwcOLqLJaVqY2j1uITHk4i?= =?us-ascii?Q?pU/Wt0qQ/nXBvcNxvZB8InWRbkBXbyd2Ss9TlyuhrZKrNCURYcYRbczjfo68?= =?us-ascii?Q?A+6U57SNR8GlEmsArLW+FsJwSIg7ooLSGlH5wdCfpOxPiWUu2YbEsy9znt4g?= =?us-ascii?Q?S6ABg93Zuy9+/vx4Cv+UPw+Yp4r1qWvQI2JlCs0?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: qirsaaB+JL+8JcKJKQ4pUpdb40MB32tU2CHuk0dy2Z06J1nNNtfpWl8NSeWETpXp8CUsgce4vyhujmbAbSLKWH4pd/9zDALOZHtnhAZrsFtltQ5KnZ1fslrZ9RTuHu3ryLfAFdGQ3jhGz/TCtY2l0tAqoSvtpKKfPmOSO7ODZ6dp0ZeiXwEtR5JE9eR34VYMYs/rAvEPdH5k50dmQKum73X/1tbDFBqYcj+J/gPUsBvBuclkyOywyUmh6feyc+SfSJAvo4VrkIApwSOwYdNjwkEbx0NwdTRvG3NBHP56V7/g2C2LrVc8pN7tll75QuRYyfbFF3U99LI4BntmB81Vl8f9K7nk6mTwzk3RrH/p8nTTX0o7In5mqR/IMS/27x2S53Nf83F5FIwOiOthBbdONBwMMz2F1WQQcxguo9pQ3eE= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Feb 2019 14:28:45.7969 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3ec64317-f7fe-46ec-eb43-08d698d20dc3 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: BN6PR01MB3284 Archived-At: Subject: Re: [kitten] resend: [OPS-DIR] Opsdir last call review of draft-ietf-kitten-pkinit-alg-agility-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, 22 Feb 2019 14:28:59 -0000 Hi Scott, I think the original at least partially worked, as the authors/shepherd have told me they plan to update the document accordingly. Thank you for the review! -Ben On Fri, Feb 22, 2019 at 09:26:11AM -0500, Scott Bradner wrote: > I am resending this because the review tool seems to have failed to properly distribute it > > Scott > > > Begin forwarded message: > > > > From: Scott Bradner > > Subject: [OPS-DIR] Opsdir last call review of draft-ietf-kitten-pkinit-alg-agility-04 > > Date: February 17, 2019 at 3:21:29 PM EST > > To: > > Cc: kitten@ietf.org, ietf@ietf.org, draft-ietf-kitten-pkinit-alg-agility.all@ietf.org > > > > Reviewer: Scott Bradner > > Review result: Has Nits > > > > This is an OPS-DIR review of PKINIT Algorithm Agility > > (draft-ietf-kitten-pkinit-alg-agility). This ID updates PKINIT following the > > guidelines in BCP 201 to make it algorithm agile and to expose acceptable > > algorithms. > > > > This is a very well written clear document. I do not find any operational > > issues with the document except that the document could use a section on > > interoperability (old server-new client, new server-old client). > > > > There are a few words about the topic deep in section 6 about the supportedKDFs > > field but I do not see a general discussion or a discussion about the kdf > > field. The text about the supportedKDFs field could be moved to a new section > > and each of the old/new combinations could be addressed. I see this as an > > operational issue because compatibility issues are a frequent source of > > operational headaches. > > > > > > _______________________________________________ > > OPS-DIR mailing list > > OPS-DIR@ietf.org > > https://www.ietf.org/mailman/listinfo/ops-dir > From nobody Tue Feb 26 08:17: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 8815712F1AB; Tue, 26 Feb 2019 08:17:52 -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.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: kitten@ietf.org Message-ID: <155119787250.736.3901367040460293342@ietfa.amsl.com> Date: Tue, 26 Feb 2019 08:17:52 -0800 Archived-At: Subject: [kitten] I-D Action: draft-ietf-kitten-pkinit-alg-agility-05.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: Tue, 26 Feb 2019 16:17:53 -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-05.txt Pages : 19 Date : 2019-02-26 Abstract: This document updates PKINIT, as defined in RFC 4556, 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-kitten-pkinit-alg-agility-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-pkinit-alg-agility-05 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 Tue Feb 26 13:48:08 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 F0D6F12D7F8; Tue, 26 Feb 2019 13:48:01 -0800 (PST) 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 kqwJfo79gwbU; Tue, 26 Feb 2019 13:47:59 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770127.outbound.protection.outlook.com [40.107.77.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1B912D7EA; Tue, 26 Feb 2019 13:47:59 -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=hPJbPl5hHAWGHf5ZeqK/FviPmerWWKOE3h8sjAFVAVk=; b=nwMi22kaFSt5xF4HWGGjZ+NVb123ltd2yvUA2AdrVFFOd0wa1N3+IPLA1Nk4Vf/ZRy3ZMvlrbA8IIHOIgpcoIhLsGFsZlkxgX01S+g0FWEUmXa3jjD/WktIvnNNAjusKGcSDtBcADnU4f1v0vUvz1l2oLmtlnmqzwkJUDDDlR7c= Received: from SN6PR01CA0026.prod.exchangelabs.com (2603:10b6:805:b6::39) by BYAPR01MB5605.prod.exchangelabs.com (2603:10b6:a03:127::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.18; Tue, 26 Feb 2019 21:47:57 +0000 Received: from CO1NAM03FT058.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::208) by SN6PR01CA0026.outlook.office365.com (2603:10b6:805:b6::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.18 via Frontend Transport; Tue, 26 Feb 2019 21:47:57 +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 CO1NAM03FT058.mail.protection.outlook.com (10.152.81.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13 via Frontend Transport; Tue, 26 Feb 2019 21:47:56 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1QLhocj009889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Feb 2019 16:43:52 -0500 Date: Tue, 26 Feb 2019 15:43:50 -0600 From: Benjamin Kaduk To: Scott Bradner CC: , , , Message-ID: <20190226214349.GA53396@kduck.mit.edu> References: <155043488911.4083.7977373920397028733@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <155043488911.4083.7977373920397028733@ietfa.amsl.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(39860400002)(136003)(376002)(346002)(2980300002)(51914003)(189003)(199004)(6916009)(88552002)(956004)(33656002)(97756001)(426003)(446003)(11346002)(336012)(2906002)(126002)(476003)(486006)(50466002)(23726003)(26826003)(478600001)(4326008)(75432002)(55016002)(104016004)(6246003)(76176011)(7696005)(786003)(316002)(36906005)(46406003)(26005)(16586007)(186003)(58126008)(54906003)(47776003)(229853002)(106002)(1076003)(53416004)(246002)(106466001)(305945005)(356004)(5660300002)(86362001)(8936002)(8676002)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR01MB5605; 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: d0c2a47b-20b1-4131-9993-08d69c3411b4 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:BYAPR01MB5605; X-MS-TrafficTypeDiagnostic: BYAPR01MB5605: X-Microsoft-Exchange-Diagnostics: 1; BYAPR01MB5605; 20:87XlWICkaLMaLtSqVI6Ic261k01pCqGs4debr9KTda0Z9zxyAB7jnnuvxy+xafHNdqt+mr6d1+AbYakRts+nBL/qI5sS7YB/S0ybUbL0BnpVPDJjMnvjEwI4X4Ln4fnsvbzM/bPYh8PZa4ED7fT3V3Lqd+6tejhVb6GDid2uT/8YhdSKPD+c8QPc7Z89rbBQ2g/I5kZazUlx+wXubt3yrBzrwsKfCRbPxnO05sv90RDMw1CcvVUYbHz3k+K3ZWjdfr4SUk0lCgxA8fsXlPWEQ2Ilrz922LAgPuzYSBSrXglTy49irn8b9VxHTt0duhURrxrzD69jcUiEEkfohBsvYhwHrERowhQojYs4IZmBhngVJB9xQAfo/0lskP60dYs1T4r7By2yE7q1YjkmKOyHrg+q5g2WkwrTOt6iRBa0Pz7eFez7w7rfIbtI5lhHXeIJMINRi9wevkp06nrsrkRP4ZDnotdQ+F6i1SfnP0HNcau+rxC3PtGTnT8pkMRH84ctySQTQdKB6o/NJ0vBtwDrjHDJgT6pWN//tG8guwwzxTFkkUvjcBdxd92UypIJA+zMC1u38LNbusNBg22vbiFVw/VLxDj8hYYiCiAl5GoxXGc= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 096029FF66 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BYAPR01MB5605; 23:YXBygQe/1pdRvIDHlRtOilxEoV6+mY6ZB320Mt+Tn?= =?us-ascii?Q?Lm3IfuKjIz0nlgxRtNfL9DbgJaFIDpD02NmuLU1qng8Vo257MC62fepyzFZj?= =?us-ascii?Q?rwthajRFQQzsI7wXl+turijCl/lTq2o56dvsHwgalwEIhHtGirMLKbppaNLf?= =?us-ascii?Q?MrFrzq45EKfpH5e0sX6thOcKf2sAIUDNTtBPgIut6gvb+EDw70X2MGnBSJII?= =?us-ascii?Q?V9/50ULyqy2b6NanmNBmEYZ3SXPg51qhyN1hqA/apZdAccEIp3JcLq9cEhKr?= =?us-ascii?Q?4qVUhAoYN4uwihWhQcUzuebRr+tto01uLp2QKWELzxrXozLjwNL1fA5z4jJk?= =?us-ascii?Q?kBWJcC7sBbYj09vHA9Jr2t9E1lxlumAEuwARvH4J/A8N3vldlNBU2yIHZITK?= =?us-ascii?Q?nEVXnSS6I70m5GzI04eUI9a+nBTdkvOEv3/x7enyUvUiED3R32mZoUUTy4pl?= =?us-ascii?Q?wc1yGA4cEJbNQuC4EHEYSaDTYYtHJe8kD0iQXpNnFWS95SDy/NwoUFDUnbUA?= =?us-ascii?Q?kkm+mphZyXIS8YsrbqQvh0QoCD5CvakAGXSsloRNb6i3HidjIyH6Qq9R8wdx?= =?us-ascii?Q?65jiL8yvSkx/Q3MEvxRI1o+KM7rh8dqBEU1qOlanCK9Bq6+CwQu+RtLMnQXD?= =?us-ascii?Q?OkO/9cxs0UE13wnu8faQ+PPKSAx6W1QyqnEU7yhP3dogvhljSZ1VEXVcXDcE?= =?us-ascii?Q?BuCG9DJB2uL9CYUoxOHfnbShj4cQdeTcZSgnSHp1txURPCb0GThsXhn204Jj?= =?us-ascii?Q?ehi2XKWn0L/FoNLAhE8xg5Yha/A8O3ZZ4BSVgsis9JX0EShpV2glf8u/dsAe?= =?us-ascii?Q?+TSaeyr5Pwwpo2oHjvJnnVx0/JUE3mM6vw5HWDbuhm/Qh3VZqURjRAx3K9ic?= =?us-ascii?Q?gYSICVcpYXzzY9TYz9PIJAU0MPa4mblSmbZ07nTsrXtLOgKPGwLtFFFBLeix?= =?us-ascii?Q?RBbDJzQEZ7URGqfIy7SSWQ7K6mu7v/zlYKgwWdTxDYj2NXP5Ng1MoQm0pnT+?= =?us-ascii?Q?fSd2kgA+Q9P49o51uy/0HOJf2gxCmp7cMw/09gEDyW25dtIOgSaYuc6NeEzj?= =?us-ascii?Q?ZWtKjtOQs+h8v8NCYnLI+AKOREibZV0m6c5NXcU89ssdllB9xlrGxWYc8PeT?= =?us-ascii?Q?5dujaFexXmW+WOk7/9hFoccOVdB/PMtQNzPOZhblo1x8HNCKplIJGemxUkP4?= =?us-ascii?Q?+U6Pzf55Aru6oF30uEUbmzMqsqetRqSYsaPztjXK7oe3Yce0Rzsxgi8jg=3D?= =?us-ascii?Q?=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: g1jWr67flTBl9lcO0Hrq+VnMQ0i4OkTsoRJ9LWGe8RKcnl44n0GJYuDFH35uf3FlqTJ1XUrVNgO4hgIEdzhLBtw+4ewmVDQWNaJHR6c3iStAkEhO1BrsOHvde7Z62M/+ZE5q9qBZZLCWo//IwymAkbInoPo4YxGedPhjNxvTDozjx8u73Ky6su6Q1a6M3whDI/vpLRSGm3ujlaFcXuLFTkJQ3mZToMRgMdVRIwE8ONcdtdvs/9TJCLGIhBAr8JnM8qGq6ZzbXaJJdI7XLw0R0LzVjCRf8CbVvV+tVVHvICS+xm6wJghVJ7x8lZQyhurG5q1jtKL5mfOtdeTruQV3FdC5Ki1qI3khuROyVca2kZSzPkxzxgfet/rSHof6ya1odPbY6Ys1JMFULxcksmYvcLa5a6qCChjbBYq6/pLwXT4= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Feb 2019 21:47:56.5542 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d0c2a47b-20b1-4131-9993-08d69c3411b4 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: BYAPR01MB5605 Archived-At: Subject: Re: [kitten] Opsdir last call review of draft-ietf-kitten-pkinit-alg-agility-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: Tue, 26 Feb 2019 21:48:02 -0000 Hi Scott, On Sun, Feb 17, 2019 at 12:21:29PM -0800, Scott Bradner wrote: > Reviewer: Scott Bradner > Review result: Has Nits > > This is an OPS-DIR review of PKINIT Algorithm Agility > (draft-ietf-kitten-pkinit-alg-agility). This ID updates PKINIT following the > guidelines in BCP 201 to make it algorithm agile and to expose acceptable > algorithms. > > This is a very well written clear document. I do not find any operational > issues with the document except that the document could use a section on > interoperability (old server-new client, new server-old client). > > There are a few words about the topic deep in section 6 about the supportedKDFs > field but I do not see a general discussion or a discussion about the kdf > field. The text about the supportedKDFs field could be moved to a new section > and each of the old/new combinations could be addressed. I see this as an > operational issue because compatibility issues are a frequent source of > operational headaches. Thanks for the review. The authors have posted an -05 that appears to address your concerns. Thanks to the authors for the updates! -Ben From nobody Wed Feb 27 03:17:55 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 79C5B129741; Wed, 27 Feb 2019 03:17:53 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 iyqzDxDECr6Y; Wed, 27 Feb 2019 03:17:51 -0800 (PST) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 AB7BF128CF3; Wed, 27 Feb 2019 03:17:51 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id d18so18619688qtg.12; Wed, 27 Feb 2019 03:17:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IY4fTH58iZ3dWOvIB1sHzrFFbqqK7/8xlMl1AiZfXZc=; b=lC9MyCqCWI8GLSyW1sAjp7rZHwXQsFOQ9I3f7HEc/Pm4Rnv+aaRkhPdggSCHHfocn/ MPATJtTxPfiAufnuzrh6H2M9O6WQDqanbik/6XENahy3vjZ3nOKXpaSJhDdkaPu91FUR lIkfvr0sfR66uevNAuHsxzw5RafhcPin+DxpSTYAjRb+icA4bWrsvQSKQ4QMO707SqrX 4SDpYjfFUaGArW22yRkDEecpcl/pPug4gSpTlSQyGe+83xJDVs7ISPmjUrIwSefPZORi I/UpyESqGNug7nEuz2OHeOjiAS99DPC7ihUfbaeoA9l18fVv7lSveoth9ivmKXXTA1y/ cH+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IY4fTH58iZ3dWOvIB1sHzrFFbqqK7/8xlMl1AiZfXZc=; b=TQLaAoWyphdwUKPXrjVj56XWh4CeUYLpTOxuSXB0vV9YWytqZRY+p428tMaEE+p4kB 2hp1GEWdtIRHCAhkkFwFe5UBxjITwmrMhGNtVIX8wJbZsEAG5zZILewEJ0UV0LWbdort GPVfLTsSSWLezH5ZNndTTB3hFdI4UFFD+oof7BShUEZlrlnMkr0z+eltLzHiUkDRN/dJ pNjtD+A9sS9TpiaFswkRkwG0D4Z3c+/UZvf+XGn7HxfEelhinE/xnego22a0opG4NcQa sbq75v9pERaOMubzis9FCUnRm6zn9+BbIxrYUrfoHStEcdwGTuvfyyu3LIpoddPiKwOQ VjbA== X-Gm-Message-State: APjAAAVVUybzT3h4Rms0FhYxVaj8q7Pho0Hl9cBs8vY+mQNjTWn6B1uk 6efN/8K0fdc+y3WA+NYQfpQ= X-Google-Smtp-Source: APXvYqx9Mete6FbQ8sv+VaupiW4IhxU92yYlZ2nFVAubo8Bxc6rAJZ++BGVGVgWLIRQEczbL1COhoA== X-Received: by 2002:a0c:8b63:: with SMTP id d35mr1395893qvc.148.1551266270891; Wed, 27 Feb 2019 03:17:50 -0800 (PST) Received: from golem.sobco.com (golem.sobco.com. [136.248.127.162]) by smtp.gmail.com with ESMTPSA id c2sm15082613qtc.41.2019.02.27.03.17.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Feb 2019 03:17:50 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Scott Bradner In-Reply-To: <20190226214349.GA53396@kduck.mit.edu> Date: Wed, 27 Feb 2019 06:17:47 -0500 Cc: ops-dir@ietf.org, kitten@ietf.org, ietf@ietf.org, draft-ietf-kitten-pkinit-alg-agility.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3CABCE27-FD27-4AFE-B7C8-73F315ED8092@gmail.com> References: <155043488911.4083.7977373920397028733@ietfa.amsl.com> <20190226214349.GA53396@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [kitten] Opsdir last call review of draft-ietf-kitten-pkinit-alg-agility-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, 27 Feb 2019 11:17:54 -0000 looks good to me thanks Scott > On Feb 26, 2019, at 4:43 PM, Benjamin Kaduk wrote: >=20 > Hi Scott, >=20 > On Sun, Feb 17, 2019 at 12:21:29PM -0800, Scott Bradner wrote: >> Reviewer: Scott Bradner >> Review result: Has Nits >>=20 >> This is an OPS-DIR review of PKINIT Algorithm Agility >> (draft-ietf-kitten-pkinit-alg-agility). This ID updates PKINIT = following the >> guidelines in BCP 201 to make it algorithm agile and to expose = acceptable >> algorithms. >>=20 >> This is a very well written clear document. I do not find any = operational >> issues with the document except that the document could use a section = on >> interoperability (old server-new client, new server-old client). >>=20 >> There are a few words about the topic deep in section 6 about the = supportedKDFs >> field but I do not see a general discussion or a discussion about the = kdf >> field. The text about the supportedKDFs field could be moved to a new = section >> and each of the old/new combinations could be addressed. I see this = as an >> operational issue because compatibility issues are a frequent source = of >> operational headaches. >=20 > Thanks for the review. The authors have posted an -05 that appears to > address your concerns. >=20 > Thanks to the authors for the updates! >=20 > -Ben From nobody Wed Feb 27 09:25: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 F191213102A for ; Wed, 27 Feb 2019 09:25:44 -0800 (PST) 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 VifABVn2Mszh for ; Wed, 27 Feb 2019 09:25:43 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740131.outbound.protection.outlook.com [40.107.74.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0271C130EE1 for ; Wed, 27 Feb 2019 09:25:42 -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=YeVNaVsSG6nG2APuPsB7OcHr1TmEU4DrLNXwlwcCM5M=; b=FP7F2zrEuCNlB/vSTv8aHcU+P4gwNqIc5iLk4x51fKJP+NDKKp/d8CLBHwXReb/93a9fClmetKoeAnomWxXuWSFJYJ1wfSJG1KpWANGEsiEpMkQotitiDgLULbaWIXsSGdVKR6HDCTARvgoIUUZzlTjMs4I/v9TGr4W3Vrdw+H4= Received: from DM5PR0102CA0014.prod.exchangelabs.com (2603:10b6:4:9c::27) by BN8PR01MB5604.prod.exchangelabs.com (2603:10b6:408:be::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.15; Wed, 27 Feb 2019 17:25:40 +0000 Received: from DM3NAM03FT053.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::202) by DM5PR0102CA0014.outlook.office365.com (2603:10b6:4:9c::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.18 via Frontend Transport; Wed, 27 Feb 2019 17:25:39 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; mit.edu; dkim=none (message not signed) header.d=none;mit.edu; 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 DM3NAM03FT053.mail.protection.outlook.com (10.152.83.181) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.13 via Frontend Transport; Wed, 27 Feb 2019 17:25:39 +0000 Received: from [18.101.8.221] (VPN-18-101-8-221.MIT.EDU [18.101.8.221]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1RHPaHs006669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Feb 2019 12:25:37 -0500 To: Sam Hartman , Sam Hartman CC: References: 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: <65c84426-b909-244a-5721-3883141082d2@mit.edu> Date: Wed, 27 Feb 2019 12:25:36 -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: 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)(136003)(376002)(39860400002)(346002)(2980300002)(189003)(199004)(51444003)(65806001)(486006)(478600001)(11346002)(426003)(2171002)(126002)(106466001)(476003)(88552002)(2486003)(446003)(26826003)(2616005)(23676004)(956004)(36756003)(336012)(4744005)(246002)(6246003)(305945005)(4326008)(7696005)(76176011)(53546011)(36906005)(106002)(65826007)(2906002)(47776003)(50466002)(186003)(5660300002)(110136005)(6706004)(85306007)(786003)(316002)(230700001)(64126003)(8936002)(58126008)(6636002)(14444005)(31696002)(31686004)(75432002)(86362001)(104016004)(356004)(65956001)(26005)(8676002)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN8PR01MB5604; 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: 0e632d72-e530-40c2-9a14-08d69cd897de 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:BN8PR01MB5604; X-MS-TrafficTypeDiagnostic: BN8PR01MB5604: X-LD-Processed: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; BN8PR01MB5604; 20:IHOO/qCr9+0fa8A2nBZCgJkPcvx6zUB744Ne2bHfivwJWPgJ8Rvke33c00ZVU95bS8B0QSAui+cfSySPILPQr9p8s1hO/Vo8unVhHnXYBs4pKdRQ+5wDYECEm0UTztDSTGKfjMlPKVyBst3mY4rDsMygFeWUm1RhyAaW0LQEg3iMkR643E1u2pFJ6SJ4OSDfxSLmnxlpjndve8HHcCtkCAEImqIq17kV2F7eLz6cCaQodPdKuSk/5PVG0L8f4wMyZz0BZ8PyPYIKsVrMOopzvbJhg36r5MrR0V9JZV3c84hTJl3aSywql9BmvDw+T1qQo9+qzJ2m8RY/koeMA3LpsW7Wu6l2UumbXBveupneqwj1val9KEyiroagnY3aq5+i3+x5EyrSdvFf62NBYdKO3wbdT3WWFbO/Q/yS44aZtFhK3N5Kih7TQXhBtlvjnl1MNDhzpXsX47xLeJ0IKtM8CDMPK5dbYp8YCwETYyNhqGMHgXvaQTcLqUd9hwNJamAsd0E9xpOmuiqZbif+kzWr460iKbTMhyUhu0BERFSTa+2t00HEjiCfuvXHrilpDJnZ3o3YwHj/AUe/N9fvdGNXeCCMR6e3EHRLu7Wl0xcnnHk= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0961DF5286 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjhQUjAxTUI1NjA0OzIzOjlvaUdjS2szSWZZQXlYa0pXenhCejNkWWlh?= =?utf-8?B?d1lGaHlDcGJwbGFDVyszN0kwU0V0UElpRTlXMmdhSlBqbnc5RUUvZTZUaGlx?= =?utf-8?B?dTdscFBIY1A2VjFRRTdOTnFwNGdqUXU4alIwRE5KYTJBbllJUXZsN3RjKzc5?= =?utf-8?B?QlcyNHZESG9OT0UzQzFTTXRicmpzejNNMFIxdXFkdXl0S0RzaE9TdmFzTURO?= =?utf-8?B?ZWU2NGFoN2E5UmVEL2RyKytEVTdyb2lPeXNkRFFYeWJNL2twbHMwbVpKNFE2?= =?utf-8?B?M3JtcGN2TWk2Rm93MUNIRDE1MnZDZlYrTW1TVDg1YVA3cElERDJaM3ZNcEZC?= =?utf-8?B?OFVGRDIvNFhKdVFIUGVwUnFrK3l4L2lPTW04UHlGNjVhSUhtSWJiTXREcFNV?= =?utf-8?B?c1h2Z2JXKzJNcjY4QmJxeFZtb29GNU9ncUZjaFNKQ2xlUFAycXVWSVhiTjNa?= =?utf-8?B?N2xXRWJZeFkxSFZNZTNtVUE0MER6UXFCMTZ3NlFEMXgxN3pPU3YzdGE0bkV4?= =?utf-8?B?d0UzTzFINk05RWdGbEVUMndNZDJvaForRlluZXFhbjhMU3E1dm1KSlgyVFNt?= =?utf-8?B?T0QyZVJ0dWUyZERIc0I0c0k2d0VhcjJPVHM1V05FbHFSRzdWZFNtNjFQUitV?= =?utf-8?B?d3pXMkFyc1psVDdkMVM0KzJGOXZodlBmTTJBQ0x2MzZMSHI2NTl3N1M4eDhn?= =?utf-8?B?VTZQOXE0TWxpRlRiWkk3S24zaHdFZnp2Q1Q4YmV2Zi96Zzl1ankrOVZpbTc2?= =?utf-8?B?ZWNvWFlMekdoZE53V2FOZnhBNmJHcDVZNEVJVzg0Q2lQT25RUFMzdkJZRW14?= =?utf-8?B?NkJkcFhDL1NmTDF0RnM0NzFScGNaL0lVekcvb2tkSHY0MXIrZzNEYnczNXFy?= =?utf-8?B?VHZ3MjRMQ1JXaWh0OEYxVU1yMXkzRExUMmxGRXlhZkRjME50L1VJalFrb2I1?= =?utf-8?B?TmlFNkNYK0s3K1kwOVh2cnBOdzBiOXA1K2lQTENLc1RFSFRnb05xajR2OHRZ?= =?utf-8?B?eHU1RHNCNm5sSFgwZTJHZGNESXc4UE5oOFI1UTFsVXZBRWJOSEN4Z25SaHNC?= =?utf-8?B?RzVxWHJuQ3NQMUZFMUl4a1hrQXd5YzVLY1dlMnNXSzVTdzlLMmRwZ1REMmp3?= =?utf-8?B?WHVtdmZwZGt4M2NUc2N3UDhTbG5jZTdzZ083QjFmbXhRSmlrRmhwcUNBbFov?= =?utf-8?B?c3JoU2IzcndjQnc5SHFaN1BnQk16WTNiMU9lNXlRbHRNUURHMjY5Ly93Ni9i?= =?utf-8?B?ZUN1WVgrUEhtbks0N0NlOWxZbXlyVURIN2YzWkFDRkQrRGJMTitrL28yV0Fq?= =?utf-8?B?a1dYYnVtVDVXMnJWMVpmamZ6b2RDQlJ0NHdPMXZTUURGOXNQOWxQS1Z4a2VW?= =?utf-8?B?WExLRXhZRUdycWVCaFFvYlNxSVUxRG5zcEhJYnUvUnJaWUlidEVreTlhZ1dL?= =?utf-8?B?Q2w4MklYeHM1RWFqNCs2NDZOZkdUOUpTS212bkZ4UkEyTkZRTFpEMWN3RUls?= =?utf-8?B?ZVB0cjE5c1Z5SG8rdit2cHowWTJFOXAxNEVCZllyTkYrb1liM1FndTRZMUVJ?= =?utf-8?B?am0vdFl1SjdwRU9OVEdpZU1DTDZLSm4zSERkMVVyeW15Wi9LYUdXVHREc2lr?= =?utf-8?B?a1pDcnhxc3lhMzhzbzhvQmE2cFR2WXZIS2JjRDFuMk1YaDBSblZORGZXNHdI?= =?utf-8?B?N2o5aWZVclRrUEpGcWV0NmpHdll5SFdvUjBPOXI3TE82eUtRVHdXSUtobEdF?= =?utf-8?B?TERWUHgyd2tXaEZFa041VE9PckRMZW45N2EwWmp0a0IyK1haditOZ2RiVk5s?= =?utf-8?B?ZHduWWIrMGxDSXI1UG9TTjFWa3NxVjRMbXFmWEprc1JxVVl2MzMxMGdpMEZ6?= =?utf-8?Q?nIvdRtoKGiI=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: yYcRJzty5Hu+EhnSeR3uRuaFx0DUPWoK3eZHrJj5Nn2MCnpIEuFXDbqmMwwHkiJLDnN3I1eEHNaXnlODHsEBQFF40AwuX884ZQem/DGLLQbsXwtUSMSixEizLVHv7HDOmD04ytSVDLmwNr3PZl+Zx5WQYz40PjIz1ub+f6rM3U5H6WVpQ9adJYhF/hpvhPytgU84Cx44MCGZ7+dkf+vWksAAL8rf9tGP0zCj7YNfWM+8X7E06xtDRD9P9dra+mcik8LTKRxx9tqmTqgshhYpPfIt0kjr74RIJ3VwPa6TUTTxB+4KhLpw32ufsh64m5V74HFNejVA6ARjkRtUfOnZbbrlH22ruh0dMWB1RVTQ790W1sZGabgdplniFRTsgsWdxv2lpxc44j2Mu5/bTivF3Jk2DDyJX3HLqglStvYF+2o= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Feb 2019 17:25:39.1178 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0e632d72-e530-40c2-9a14-08d69cd897de 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: BN8PR01MB5604 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, 27 Feb 2019 17:25:45 -0000 On 2/18/19 4:39 PM, Sam Hartman wrote: > However, I think that the decision as to what to do should be based on > analysis of applications where one side uses channel bindings and the > other does not. Since I'm not actually aware of any significant > applications that do that, I'll hold off until my previous question on > that issue is answered before forming my opinion on the correct > behavior. I think the practical motivation for this draft is a desire to add channel bindings to application protocols which do not currently use them. I believe HTTP Negotiate is commonly given as a candidate. So, while I am not sure there are any applications in this category today, there is a desire to (at least temporarily) create some in the future. From nobody Thu Feb 28 08:03:37 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 A0732130F03 for ; Thu, 28 Feb 2019 08:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.253 X-Spam-Level: X-Spam-Status: No, score=-0.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_SOFTFAIL=0.665] 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 E4x6Qs5ZhM-6 for ; Thu, 28 Feb 2019 08:03:33 -0800 (PST) Received: from mail.suchdamage.org (ec2-52-9-186-167.us-west-1.compute.amazonaws.com [52.9.186.167]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7648B130EF1 for ; Thu, 28 Feb 2019 08:03:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.suchdamage.org (Postfix) with ESMTP id E2C882D128; Thu, 28 Feb 2019 11:03:32 -0500 (EST) Received: from mail.suchdamage.org ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KubfkHJMJs6G; Thu, 28 Feb 2019 11:03:32 -0500 (EST) 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; Thu, 28 Feb 2019 11:03:32 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9B0EEC0DD1; Thu, 28 Feb 2019 11:03:30 -0500 (EST) From: Sam Hartman To: Greg Hudson Cc: Sam Hartman , Sam Hartman , References: <65c84426-b909-244a-5721-3883141082d2@mit.edu> Date: Thu, 28 Feb 2019 11:03:30 -0500 In-Reply-To: <65c84426-b909-244a-5721-3883141082d2@mit.edu> (Greg Hudson's message of "Wed, 27 Feb 2019 12:25:36 -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: Thu, 28 Feb 2019 16:03:36 -0000 >>>>> "Greg" == Greg Hudson writes: Greg> On 2/18/19 4:39 PM, Sam Hartman wrote: >> However, I think that the decision as to what to do should be >> based on analysis of applications where one side uses channel >> bindings and the other does not. Since I'm not actually aware of >> any significant applications that do that, I'll hold off until my >> previous question on that issue is answered before forming my >> opinion on the correct behavior. Greg> I think the practical motivation for this draft is a desire to Greg> add channel bindings to application protocols which do not Greg> currently use them. I believe HTTP Negotiate is commonly Greg> given as a candidate. So, while I am not sure there are any Greg> applications in this category today, there is a desire to (at Greg> least temporarily) create some in the future. HTTP negotiate seems like it will be an interesting design thought exercise. While working on Moonshot we spent some time trying to figure out how we would approach channel binding for HTTP negotiate. It seemed like deployment considerations made it kind of tricky. Do I use unique or endpoint channel bindings? That depends on several factors: * To use unique channel bindings I need to produce the GSS-API token on the client after the TLS connection is established. That assumes a certain model for how the HTTP and TLS libraries interact. * To use unique channel bindings on the server, I need access to the appropriate hashes; that assumes my HTTP library and my TLS library make that available to whoever is producing the GSS token. (In many but not all cases that will be part of the HTTP library) OK, so just use endpoint channel bindings and be done with it. Does the server actually know its endpoint channel binding? If it's behind a reverse proxy, that may depend a lot on the configuration. TLS may terminate at the reverse proxy. The connection behind the reverse proxy may be unencrypted, or it may be encrypted using a different certificate. We don't want to break things that work today. Yes, channel bindings would make that situation more secure, but HTTP negotiate has value without channel bindings, demonstrated by the people who use it today. Also, we've already found bugs in channel bindings (even for TLS). So, we probably want some sort of transition strategy. So, it seems like you're almost always going to want some application layer something to figure out whether channel bindings are supported on both ends and whether to use them. (And probably if they get used a lot, which channel binding to use). That's frustrating because it makes channel bindings not so simple. Some thoughts: The Moonshot behavior (null acceptor bindings ignores any initiator CB) makes it easier for people to withdraw from the channel binding process when local configuration does not support channel binding. If it weren't for there being multiple types of channel binding and a need to think about transitions, I'd argue that makes the Moonshot behavior clearly supperior especially if there are not currently applications that don't know whether they are doing CB. Given that we probably should care about those issues, I'm not at all sure I know what the right behavior should be for applications that do not support this flag. I'm still definitely in favor of the flag. The more I look at this, I don't think this is fixing a flaw in GSS-API, and I especially am not seeing the security flaw. I think it's adding a new capability with some tricky interoperability and deployment considerations.