From nobody Mon Dec 3 10:42:47 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FAC91271FF for ; Mon, 3 Dec 2018 10:42:46 -0800 (PST) X-Quarantine-ID: <2sOgEYptT770> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...ghudson@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...] X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sOgEYptT770 for ; Mon, 3 Dec 2018 10:42:44 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 374E21200B3 for ; Mon, 3 Dec 2018 10:42:43 -0800 (PST) X-AuditID: 1209190e-beb2c9e000004296-c4-5c05792297e3 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id EB.61.17046.229750C5; Mon, 3 Dec 2018 13:42:42 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.14.7/8.9.2) with ESMTP id wB3Iebxm014145 for ; Mon, 3 Dec 2018 13:40:38 -0500 Received: from localhost (SMALL-GODS.MIT.EDU [18.9.55.42]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) œby outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wB3IeZVs018205 for ; Mon, 3 Dec 2018 13:40:36 -0500 From: Greg Hudson To: kitten@ietf.org Date: Mon, 03 Dec 2018 13:40:35 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUixG6noqtUyRpjsHu3icXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcbv7GFvBJIGK65PnszcwzuTtYuTkkBAwkViw+gNrFyMXh5DA GiaJE6eOsEM4xxglzh67zwzhtDNJ/Fm2nRmkhU1AWWL9/q0sILaIgLDE7q3vwOLCAtoSx39f YwexWQRUJVatv8UIYvMC2VN6N0DZghInZz4B62UWkJA4+OIF8wRG7llIUrOQpBYwMq1iFE3J rdLNTczMKU5N1i1OTszLSy3SNd7ECPI7pyTfDsZJDd6HGAU4GJV4eGc4scYIsSaWFVfmHmKU 5GBSEuVdGQQU4kvKT6nMSCzOiC8qzUktPsQowcGsJMJbUMgSI8SbklhZlVqUD5OS5mBREuf9 JfI4WkggPbEkNTs1tSC1CCYrw8GhJMH7LRNoqGBRanpqRVpmTglCmomDE2Q4D9DwC+lANbzF BYm5xZnpEPlTjIpS4ry7XYESAiCJjNI8uF5wXHKaa71iFAd6RZi3owyoigcY03Ddr4AGMwEN ztnCBDK4JBEhJdXAeKvJ9o9u0+THGVnzVHb33Tx2PXf6sz8bcr/9OBujfSt9Q7R0edqy+8q1 f5vfRzyaHHTMUOqF5rwqn72XDxif/XDed9GzNJGPX3ZtWcvayuaxdOH1pafs5q75FGJvFdcx KY/lSfWr1ELHCZf3N6oZeCcxr+SV8c77tPM1C/Nn++7bTBYlhiu/yyuxFGckGmoxFxUnAgDS jb2SpgIAAA== Archived-At: Subject: [kitten] SPAKE channel ID for second-factor 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, 03 Dec 2018 18:42:46 -0000 I have been thinking recently about some security properties of SPAKE preauth with a second factor. SPAKE preauth leverages the first factor (the long-term key) to establish a channel, and then includes second-factor communication in the key confirmation and perhaps in subsequent messages. This design is consistent with the ancient SAM-2 preauth mechanism (although much better because it uses a PAKE), but is different from typical modern multi-factor authentication which tends to rely on a TLS channel (authenticated by server cert) to protect all authentication factors. A consequence of the SPAKE preauth design is that if an attacker knows the first factor (say, because of password reuse), the attacker can MITM the SPAKE exchange and relay the second-factor communication across the KDC-to-attacker and attacker-to-client channels, to obtain a KDC response the attacker can decrypt. For a simple OTP second factor, I don't know if there is much to be done. But for a challenge-response second factor like a Fido security token, I think we might be able to improve on the security properties by incorporating a SPAKE channel ID into the challenge, or simply specifying that a SPAKE channel ID is the challenge rather than having the KDC make one up and send it to the client. The SPAKE draft currently says nothing about a channel ID for use by second factors. This could be addressed in the first second factor specification which needs a channel ID, but I think it might be valuable to specify a channel ID in the base SPAKE draft. I'm thinking of something similar to the derivation of K'[n] but using "SPAKEchannel" as the prefix and stopping at the hash output step. (Thought experiment, independent of Kerberos: imagine you perform an unauthenticated DH exchange, then use a channel ID derived from the DH shared key as the challenge for a challenge-response security token. Is that secure against active attacks? I believe the answer is yes; if not, there might be something wrong in my analysis above.) From nobody Mon Dec 3 11:53:04 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E78E130DF9 for ; Mon, 3 Dec 2018 11:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gxmLCoae1OR for ; Mon, 3 Dec 2018 11:53:00 -0800 (PST) Received: from goldenrod.birch.relay.mailchannels.net (goldenrod.birch.relay.mailchannels.net [23.83.209.74]) (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 31CB512D4E7 for ; Mon, 3 Dec 2018 11:52:59 -0800 (PST) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id F23565022A0; Mon, 3 Dec 2018 19:52:58 +0000 (UTC) Received: from pdx1-sub0-mail-a26.g.dreamhost.com (unknown [100.96.19.78]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id B64385024DE; Mon, 3 Dec 2018 19:52:58 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a26.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Mon, 03 Dec 2018 19:52:58 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Zesty-Whispering: 6a5de87d79573418_1543866778850_3400231993 X-MC-Loop-Signature: 1543866778850:2714855339 X-MC-Ingress-Time: 1543866778849 Received: from pdx1-sub0-mail-a26.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a26.g.dreamhost.com (Postfix) with ESMTP id 60A757FA1B; Mon, 3 Dec 2018 11:52:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=AWuHBOUQqent73 xHFuGK7KZdhyQ=; b=bwvEsSF/jCJw7E0RzX9iMWSu/GeS28HsTg/kZ5xcsaSRvw 0hLMJ3d2RtEr4XRjXNg/fyKG6ysmgb0idUfTLE3dcbhfyi0zDLOTnYuEWzSsxACz RQ8inoCDtDybC9Ia+BrAs6atBpNyRnwilppsdNPb/fSWHTmaLF6oHn6YzzMmw= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 0EC367FA1E; Mon, 3 Dec 2018 11:52:56 -0800 (PST) Date: Mon, 3 Dec 2018 13:52:54 -0600 X-DH-BACKEND: pdx1-sub0-mail-a26 From: Nico Williams To: Greg Hudson Cc: kitten@ietf.org Message-ID: <20181203195253.GE15561@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrudefuddgudeftdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [kitten] SPAKE channel ID for second-factor 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, 03 Dec 2018 19:53:03 -0000 On Mon, Dec 03, 2018 at 01:40:35PM -0500, Greg Hudson wrote: > I have been thinking recently about some security properties of SPAKE > preauth with a second factor. SPAKE preauth leverages the first factor > (the long-term key) to establish a channel, and then includes > second-factor communication in the key confirmation and perhaps in > subsequent messages. This design is consistent with the ancient SAM-2 > preauth mechanism (although much better because it uses a PAKE), but is > different from typical modern multi-factor authentication which tends to > rely on a TLS channel (authenticated by server cert) to protect all > authentication factors. > > A consequence of the SPAKE preauth design is that if an attacker knows > the first factor (say, because of password reuse), the attacker can MITM > the SPAKE exchange and relay the second-factor communication across the > KDC-to-attacker and attacker-to-client channels, to obtain a KDC > response the attacker can decrypt. Yes. We could fix this by adding a stable public key for authenticating the KDC/realm, which would put this on par with the TLS case. This is already possible by using a FAST armor ticket obtained with [anonymous] PKINIT, though it's more costly than something more closely integrated into the protocol. > For a simple OTP second factor, I don't know if there is much to be > done. But for a challenge-response second factor like a Fido security > token, I think we might be able to improve on the security properties by > incorporating a SPAKE channel ID into the challenge, or simply > specifying that a SPAKE channel ID is the challenge rather than having > the KDC make one up and send it to the client. Even for OTP, if the OTP is "key-generating", meaning that the OTP can be used as a symmetric key and the verifier can use it as a key to verify a ciphertext / MAC payload send by the client, then it's OK. However, the simplest fix is to add a server PK to the protocol. Obviously it's a bit late for _this_ protocol, as it's been deployed, and so can only admit backwards-compatible changes. > The SPAKE draft currently says nothing about a channel ID for use by > second factors. This could be addressed in the first second factor > specification which needs a channel ID, but I think it might be valuable > to specify a channel ID in the base SPAKE draft. I'm thinking of something > similar to the derivation of K'[n] but using "SPAKEchannel" as the > prefix and stopping at the hash output step. We'd have to fit negotiation of this into the second factor type ID. Similarly, in order to use an augment PAKE (SPAKE2+), to use alternative PAKEs (e.g., SPEKE), and/or to augment the protocol with a server public key, we'd have to overload the group ID. We can do this later, and I'd rather not hold up shepherding. We can do this during IETF LC, or later in a follow-on RFC. > (Thought experiment, independent of Kerberos: imagine you perform an > unauthenticated DH exchange, then use a channel ID derived from the DH > shared key as the challenge for a challenge-response security token. Is > that secure against active attacks? I believe the answer is yes; if > not, there might be something wrong in my analysis above.) This is channel binding. Channel binding enables discovery of an MITM if they complete the handshake, but if they drop off (resetting any connections) then you only get a timeout/reset as evidence of the MITM, and the MITM gets to learn whatever metadata is available early enough (e.g., client identity). Nico -- From nobody Mon Dec 3 11:55:12 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C935130E48 for ; Mon, 3 Dec 2018 11:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTzTY4xPHnek for ; Mon, 3 Dec 2018 11:55:10 -0800 (PST) Received: from insect.birch.relay.mailchannels.net (insect.birch.relay.mailchannels.net [23.83.209.93]) (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 C2FA3130DF9 for ; Mon, 3 Dec 2018 11:55:09 -0800 (PST) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D18835C483A; Mon, 3 Dec 2018 19:55:08 +0000 (UTC) Received: from pdx1-sub0-mail-a26.g.dreamhost.com (unknown [100.96.11.179]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 8B9015C4953; Mon, 3 Dec 2018 19:55:08 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a26.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Mon, 03 Dec 2018 19:55:08 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Chief-Belong: 28cc7d530138500a_1543866908670_3482318258 X-MC-Loop-Signature: 1543866908669:2874165223 X-MC-Ingress-Time: 1543866908669 Received: from pdx1-sub0-mail-a26.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a26.g.dreamhost.com (Postfix) with ESMTP id 3D88A7FA1C; Mon, 3 Dec 2018 11:55:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=3ZI6RFm4hctk0J DjoCTZqcHewrg=; b=gauyxD2U+ANq7gCSJgtX5tLKaxvh6CKYbFchXBGSGHN2XY KevZ3pK8OiLtljCYfpPJteSGV7MJY9rjRmE5qlfTn8IHEMUWe8pl2OZkspc/bxQk 4zg5W6oDaTF4aBzdgRLhYC7GejG+PwjZjIiWoQ6BUU21qooQJasXi3Qnegtzw= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 1CE477FA03; Mon, 3 Dec 2018 11:55:06 -0800 (PST) Date: Mon, 3 Dec 2018 13:55:04 -0600 X-DH-BACKEND: pdx1-sub0-mail-a26 From: Nico Williams To: Greg Hudson Cc: kitten@ietf.org Message-ID: <20181203195503.GF15561@localhost> References: <20181203195253.GE15561@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181203195253.GE15561@localhost> User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrudefuddgudeftdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgepud Archived-At: Subject: Re: [kitten] SPAKE channel ID for second-factor 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, 03 Dec 2018 19:55:11 -0000 On Mon, Dec 03, 2018 at 01:52:54PM -0600, Nico Williams wrote: > Similarly, in order to use an augment PAKE (SPAKE2+), to use alternative > PAKEs (e.g., SPEKE), and/or to augment the protocol with a server public > key, we'd have to overload the group ID. Speaking of which, I am a bit disappointed that there's no SPAKE2+ support... Nico -- From nobody Mon Dec 3 12:27:49 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4FD128A6E for ; Mon, 3 Dec 2018 12:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTM0bcCnBWvl for ; Mon, 3 Dec 2018 12:27:45 -0800 (PST) Received: from common.maple.relay.mailchannels.net (common.maple.relay.mailchannels.net [23.83.214.38]) (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 CEB1B12DDA3 for ; Mon, 3 Dec 2018 12:27:44 -0800 (PST) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D1CD05C3E67; Mon, 3 Dec 2018 20:27:43 +0000 (UTC) Received: from pdx1-sub0-mail-a26.g.dreamhost.com (unknown [100.96.33.121]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 8E4E65C3F79; Mon, 3 Dec 2018 20:27:43 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a26.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Mon, 03 Dec 2018 20:27:43 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Reign-Average: 5088622d7543c414_1543868863682_2652585215 X-MC-Loop-Signature: 1543868863682:798713561 X-MC-Ingress-Time: 1543868863681 Received: from pdx1-sub0-mail-a26.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a26.g.dreamhost.com (Postfix) with ESMTP id 098937FA19; Mon, 3 Dec 2018 12:27:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=lihySLHqJrGyOH a5lxDGMkdVPZQ=; b=IZVkXBj5K2vft7wh4oe+onuRmplq4kQ4Noh97WyPkD9QiK sVePdGKdNWr4wLKEWdlImRJzpq77LNniQZ1t8URraroRHQJlfmgy09wbXhwz7Owx P08DyJvqIla/fXL22rqlpH+pc87XTARR/TKs4tWuhIwg3gdxLlYoBJKDupPiE= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 939EF7FA1C; Mon, 3 Dec 2018 12:27:40 -0800 (PST) Date: Mon, 3 Dec 2018 14:27:38 -0600 X-DH-BACKEND: pdx1-sub0-mail-a26 From: Nico Williams To: Simo Sorce Cc: Greg Hudson , kitten@ietf.org Message-ID: <20181203202737.GG15561@localhost> References: <20181203195253.GE15561@localhost> <19d931f12689c3e74b6d01589a24404edc3cb20e.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19d931f12689c3e74b6d01589a24404edc3cb20e.camel@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrudefuddgudefjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [kitten] SPAKE channel ID for second-factor 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, 03 Dec 2018 20:27:48 -0000 On Mon, Dec 03, 2018 at 03:24:31PM -0500, Simo Sorce wrote: > On Mon, 2018-12-03 at 13:52 -0600, Nico Williams wrote: > > Yes. We could fix this by adding a stable public key for authenticating > > the KDC/realm, which would put this on par with the TLS case. This is > > already possible by using a FAST armor ticket obtained with [anonymous] > > PKINIT, though it's more costly than something more closely integrated > > into the protocol. > > One of the goals of the SPAKE pre-auth mechanism is to be able to use > it on "unconfigured" clients. The requirement to trust a specific KDC > public key would defeat the purpose, and brings us back to the > deployment issues we have with FAST. It wouldn't be a requirement. And TOFU is certainly possible. The ability to learn realm public keys / issuers for PKINIT via SPAKE2 seems... really neat! > A form of channel binding is more desirable in this context. Yes, but that requires changing the OTP infrastructure, does it not? That would slow adoption a great deal. Nico -- From nobody Mon Dec 3 12:30:28 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC38130DF9 for ; Mon, 3 Dec 2018 12:30:26 -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 iKdoiqhL6b3o for ; Mon, 3 Dec 2018 12:30:25 -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 53821128A6E for ; Mon, 3 Dec 2018 12:30:25 -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 6DC54C059B6F; Mon, 3 Dec 2018 20:24:32 +0000 (UTC) Received: from ovpn-116-70.phx2.redhat.com (ovpn-116-70.phx2.redhat.com [10.3.116.70]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F29C45C57B; Mon, 3 Dec 2018 20:24:31 +0000 (UTC) Message-ID: <19d931f12689c3e74b6d01589a24404edc3cb20e.camel@redhat.com> From: Simo Sorce To: Nico Williams , Greg Hudson Cc: kitten@ietf.org Date: Mon, 03 Dec 2018 15:24:31 -0500 In-Reply-To: <20181203195253.GE15561@localhost> References: <20181203195253.GE15561@localhost> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Mon, 03 Dec 2018 20:24:32 +0000 (UTC) Archived-At: Subject: Re: [kitten] SPAKE channel ID for second-factor 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, 03 Dec 2018 20:30:26 -0000 On Mon, 2018-12-03 at 13:52 -0600, Nico Williams wrote: > > Yes. We could fix this by adding a stable public key for authenticating > the KDC/realm, which would put this on par with the TLS case. This is > already possible by using a FAST armor ticket obtained with [anonymous] > PKINIT, though it's more costly than something more closely integrated > into the protocol. One of the goals of the SPAKE pre-auth mechanism is to be able to use it on "unconfigured" clients. The requirement to trust a specific KDC public key would defeat the purpose, and brings us back to the deployment issues we have with FAST. A form of channel binding is more desirable in this context. Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc From nobody Mon Dec 3 13:01:53 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43418130E9C for ; Mon, 3 Dec 2018 13:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1iyOGckV7FG for ; Mon, 3 Dec 2018 13:01:43 -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 9ED02130E79 for ; Mon, 3 Dec 2018 13:01:43 -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 091DDC049586; Mon, 3 Dec 2018 21:01:43 +0000 (UTC) Received: from ovpn-116-70.phx2.redhat.com (ovpn-116-70.phx2.redhat.com [10.3.116.70]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A78595C237; Mon, 3 Dec 2018 21:01:42 +0000 (UTC) Message-ID: <2a985121caa4288a9dfbb9970b278d11241173ca.camel@redhat.com> From: Simo Sorce To: Nico Williams Cc: kitten@ietf.org Date: Mon, 03 Dec 2018 16:01:41 -0500 In-Reply-To: <20181203202737.GG15561@localhost> References: <20181203195253.GE15561@localhost> <19d931f12689c3e74b6d01589a24404edc3cb20e.camel@redhat.com> <20181203202737.GG15561@localhost> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Mon, 03 Dec 2018 21:01:43 +0000 (UTC) Archived-At: Subject: Re: [kitten] SPAKE channel ID for second-factor 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, 03 Dec 2018 21:01:51 -0000 On Mon, 2018-12-03 at 14:27 -0600, Nico Williams wrote: > On Mon, Dec 03, 2018 at 03:24:31PM -0500, Simo Sorce wrote: > > On Mon, 2018-12-03 at 13:52 -0600, Nico Williams wrote: > > > Yes. We could fix this by adding a stable public key for authenticating > > > the KDC/realm, which would put this on par with the TLS case. This is > > > already possible by using a FAST armor ticket obtained with [anonymous] > > > PKINIT, though it's more costly than something more closely integrated > > > into the protocol. > > > > One of the goals of the SPAKE pre-auth mechanism is to be able to use > > it on "unconfigured" clients. The requirement to trust a specific KDC > > public key would defeat the purpose, and brings us back to the > > deployment issues we have with FAST. > > It wouldn't be a requirement. And TOFU is certainly possible. > > The ability to learn realm public keys / issuers for PKINIT via SPAKE2 > seems... really neat! It may be neat as an optional feature, but I do not think we should add additional PK load on this mechanism. > > A form of channel binding is more desirable in this context. > > Yes, but that requires changing the OTP infrastructure, does it not? > That would slow adoption a great deal. No, the channelID Greg proposed shouldn't change how the OTP part is dealt with if I understood it correctly. Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc From nobody Mon Dec 3 13:06:25 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7F51294D7 for ; Mon, 3 Dec 2018 13:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.69 X-Spam-Level: X-Spam-Status: No, score=-0.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_RP_RNBL=1.31] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcQTv3EBhlXh for ; Mon, 3 Dec 2018 13:06:22 -0800 (PST) Received: from firebrick.maple.relay.mailchannels.net (firebrick.maple.relay.mailchannels.net [23.83.214.59]) (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 DCDFE1200B3 for ; Mon, 3 Dec 2018 13:06:21 -0800 (PST) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D9E32124971; Mon, 3 Dec 2018 21:06:20 +0000 (UTC) Received: from pdx1-sub0-mail-a26.g.dreamhost.com (unknown [100.96.36.160]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 90CF91230A4; Mon, 3 Dec 2018 21:06:20 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a26.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Mon, 03 Dec 2018 21:06:20 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Imminent-Industry: 778dc5bc42ccf5cb_1543871180707_2007227208 X-MC-Loop-Signature: 1543871180706:3770120879 X-MC-Ingress-Time: 1543871180706 Received: from pdx1-sub0-mail-a26.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a26.g.dreamhost.com (Postfix) with ESMTP id 4F8677FA2C; Mon, 3 Dec 2018 13:06:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=eNnSPSjZQbjJa2 uBL4MOxDOkJMk=; b=GAWIOrnm0ikT8KQtotSrlLQOeNPkiEx0g5BPpfGVT0Wynl I/IPy/DRvRvgv3KgGP88U0b7ppgnB5HD+6SmrlbUfmOFUF8GSmeYJWsgQTAbRIyl yCtZjbKLntc+wx1AjLggdARvNmAzxXkUUX+fxWuWKN4nMrfVm3752nTH8p8ic= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a26.g.dreamhost.com (Postfix) with ESMTPSA id C751E7FA26; Mon, 3 Dec 2018 13:06:17 -0800 (PST) Date: Mon, 3 Dec 2018 15:06:14 -0600 X-DH-BACKEND: pdx1-sub0-mail-a26 From: Nico Williams To: Simo Sorce Cc: kitten@ietf.org Message-ID: <20181203210613.GH15561@localhost> References: <20181203195253.GE15561@localhost> <19d931f12689c3e74b6d01589a24404edc3cb20e.camel@redhat.com> <20181203202737.GG15561@localhost> <2a985121caa4288a9dfbb9970b278d11241173ca.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a985121caa4288a9dfbb9970b278d11241173ca.camel@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrudefuddgudeghecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [kitten] SPAKE channel ID for second-factor 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, 03 Dec 2018 21:06:23 -0000 On Mon, Dec 03, 2018 at 04:01:41PM -0500, Simo Sorce wrote: > On Mon, 2018-12-03 at 14:27 -0600, Nico Williams wrote: > > On Mon, Dec 03, 2018 at 03:24:31PM -0500, Simo Sorce wrote: > > > On Mon, 2018-12-03 at 13:52 -0600, Nico Williams wrote: > > > > Yes. We could fix this by adding a stable public key for authenticating > > > > the KDC/realm, which would put this on par with the TLS case. This is > > > > already possible by using a FAST armor ticket obtained with [anonymous] > > > > PKINIT, though it's more costly than something more closely integrated > > > > into the protocol. > > > > > > One of the goals of the SPAKE pre-auth mechanism is to be able to use > > > it on "unconfigured" clients. The requirement to trust a specific KDC > > > public key would defeat the purpose, and brings us back to the > > > deployment issues we have with FAST. > > > > It wouldn't be a requirement. And TOFU is certainly possible. > > > > The ability to learn realm public keys / issuers for PKINIT via SPAKE2 > > seems... really neat! > > It may be neat as an optional feature, but I do not think we should add > additional PK load on this mechanism. If you're not using it it won't cost anything. Anyways, I'm not proposing any changes to this protocol at this time. > > > A form of channel binding is more desirable in this context. > > > > Yes, but that requires changing the OTP infrastructure, does it not? > > That would slow adoption a great deal. > > No, the channelID Greg proposed shouldn't change how the OTP part is > dealt with if I understood it correctly. Well, if you did then I didn't and it needs more explaining. Nico -- From nobody Mon Dec 3 13:19:23 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DAF12D4ED for ; Mon, 3 Dec 2018 13:19:22 -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 4xbraLPsn2A5 for ; Mon, 3 Dec 2018 13:19:20 -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 549A41294D7 for ; Mon, 3 Dec 2018 13:19:20 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 14FDC81127; Mon, 3 Dec 2018 21:19:20 +0000 (UTC) Received: from ovpn-116-70.phx2.redhat.com (ovpn-116-70.phx2.redhat.com [10.3.116.70]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B6DDB17BBA; Mon, 3 Dec 2018 21:19:19 +0000 (UTC) Message-ID: <3928d1ee7b90ef13ebfcd0c4b3c4a34cc82f7495.camel@redhat.com> From: Simo Sorce To: Nico Williams Cc: kitten@ietf.org Date: Mon, 03 Dec 2018 16:19:18 -0500 In-Reply-To: <2a985121caa4288a9dfbb9970b278d11241173ca.camel@redhat.com> References: <20181203195253.GE15561@localhost> <19d931f12689c3e74b6d01589a24404edc3cb20e.camel@redhat.com> <20181203202737.GG15561@localhost> <2a985121caa4288a9dfbb9970b278d11241173ca.camel@redhat.com> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 03 Dec 2018 21:19:20 +0000 (UTC) Archived-At: Subject: Re: [kitten] SPAKE channel ID for second-factor 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, 03 Dec 2018 21:19:22 -0000 On Mon, 2018-12-03 at 16:01 -0500, Simo Sorce wrote: > On Mon, 2018-12-03 at 14:27 -0600, Nico Williams wrote: > > On Mon, Dec 03, 2018 at 03:24:31PM -0500, Simo Sorce wrote: > > > On Mon, 2018-12-03 at 13:52 -0600, Nico Williams wrote: > > > > Yes. We could fix this by adding a stable public key for authenticating > > > > the KDC/realm, which would put this on par with the TLS case. This is > > > > already possible by using a FAST armor ticket obtained with [anonymous] > > > > PKINIT, though it's more costly than something more closely integrated > > > > into the protocol. > > > > > > One of the goals of the SPAKE pre-auth mechanism is to be able to use > > > it on "unconfigured" clients. The requirement to trust a specific KDC > > > public key would defeat the purpose, and brings us back to the > > > deployment issues we have with FAST. > > > > It wouldn't be a requirement. And TOFU is certainly possible. > > > > The ability to learn realm public keys / issuers for PKINIT via SPAKE2 > > seems... really neat! > > It may be neat as an optional feature, but I do not think we should add > additional PK load on this mechanism. > > > > A form of channel binding is more desirable in this context. > > > > Yes, but that requires changing the OTP infrastructure, does it not? > > That would slow adoption a great deal. > > No, the channelID Greg proposed shouldn't change how the OTP part is > dealt with if I understood it correctly. Uhmm I guess you meant wrt the use of the OTP to generate a key. Yes that would not fly. And just binding the channel based on a DH exchange without known public key does not help in the case of a classic OTP. It helps only in the case of a challenge-response token. However I do not think we need to try to make SPAKE's Second Factor extension dependent on non MITM-ability if the first factor is known. In a Password + [T|H|..]OTP scheme, the second factor is used to prevent use of the first factor without access to a [physical] token generator, so that a leaked first factor still does require a full- blown MITM to be useful. SPAKE is a decent compromise here and addresses the point w/o requiring pre-configuration of the device being used with secret shared keys or even public keys. It perform its job of strengthening the safety of the first factor. For threat scenarios where MITM is a serious issue people should probably just still use FAST. Perhaps we could add an OTP mechanism that uses KDC PKs in the second factor handling ? Maybe encrypting the second factor in a KDC Public Key if "extra security" is desired and configuring the client with keys and options to enforce this extra security is an acceptable deployment constraint. Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc From nobody Tue Dec 4 10:14:48 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4679B130E95 for ; Tue, 4 Dec 2018 10:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=secure-endpoints.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 JEBW2CbEjjIX for ; Tue, 4 Dec 2018 10:14:44 -0800 (PST) Received: from sequoia-grove.secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 663F4130E4D for ; Tue, 4 Dec 2018 10:14:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/relaxed; d=secure-endpoints.com; s=MDaemon; t=1543947282; x=1544552082; i=jaltman@secure-endpoints.com; q=dns/txt; h=VBR-Info:Subject:To: References:From:Openpgp:Autocrypt:Organization:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type; bh=4LhUF1hxWv9 lfzaKAZSDIpvfmI48gv8ufGF5g8sheYY=; b=oHSwySVjf56WGMaLGU6e2Qx34rH kUyO/BOfExZ7RW1ODLEmctbFsX1uw/XrrnUHFEE5Rya7hF0JrWssYRn6RjTZPP4o 98oaojY1ttIBYn1JroYW0L4K1LboECbTc8WBeTXBOgVrIaY2KH2UqFxpLwWlyUYT G4xSk5MDrj0dT1mI= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Tue, 04 Dec 2018 13:14:42 -0500 X-Spam-Processed: sequoia-grove.secure-endpoints.com, Tue, 04 Dec 2018 13:14:42 -0500 Received: from [IPv6:2001:470:1f07:f77:6073:252a:a261:1899] by secure-endpoints.com (IPv6:2001:470:1f07:f77:28d9:68fb:855d:c2a5) (MDaemon PRO v18.5.1) with ESMTPSA id md50001770613.msg; Tue, 04 Dec 2018 13:14:41 -0500 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-MDRemoteIP: 2001:470:1f07:f77:6073:252a:a261:1899 X-MDHelo: [IPv6:2001:470:1f07:f77:6073:252a:a261:1899] X-MDArrival-Date: Tue, 04 Dec 2018 13:14:41 -0500 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=1876b0ebb2=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org X-CAV-Result: clean To: Greg Hudson , kitten@ietf.org References: From: Jeffrey Altman Openpgp: id=FA444AF197F449B24CF3E699F77A735592B69A04; url=https://pgp.mit.edu Autocrypt: addr=jaltman@secure-endpoints.com; prefer-encrypt=mutual; keydata= xsFNBEwLlO0BEACu6yWFkd1+qwsGg8ZzgslSkcAKhSegWt5j86DpaRL0W8fxg6YjxwEPvwoH BGa/rpSdBd1gkmzeYxD3hVZdj75r6nVS9f/mxNQzW+o1sW4vaeSxKgZSQz5RqHmwPDcqQP66 +ZSnjV+G88MKwZ9DIzA9AwpJhNAAlAlj3OvsQVsxd1ipc6C4/U3qjHL7Ih22UbPBM71ltIZx kqcrAlXPnUTeraJXtfzYbq4mJFJ9JC6/o1NRSjsBvRD+ADxlG50+KccZN4SS5xxdGuh1tA9U TydYBQB3YtJbq7CYau2kIYt/3HnyLYGo1s6Ti6cuAJJ/40iIE1xkqhvMiIz/Q+1ztmksJbLQ aCtW8kF42nF8MpPdIPTSPr2uGvpRtCjRbh4lgMXgyNUx1wpCEY0X11xce++H8HySmFwryE2y kkxUQeMUjaaXZDHYUSyQz7riChFiZ9ax9dmX0wUY/A05v0qcualglpk4wJ2kcsGKUEGkLvnV wwvya8zifPwKOw5JlGPvzX8t2m7jB2GXKzvVAsImqOqnDBTKUXWQQZCW9Rqt7acdE8bQ2vqr vP+3Ykf4SrPwcuNCDt6QSgjVbhc3hA3hCtE1iW/HhuBAzKiuzJ9era+q9QjTtLPIkQDHRpcC MMWvK0Y1uQ34Ql1BfKRA4gc8A7CuVUY6+Ga7PuJWd+FSglvmKQARAQABzS1KZWZmcmV5IEFs dG1hbiA8amFsdG1hbkB5b3VyLWZpbGUtc3lzdGVtLmNvbT7CwXkEEwECACMCGyMGCwkIBwMC BBUCCAMEFgIDAQIeAQIXgAUCTAuXLQIZAQAKCRD3enNVkraaBJDnD/9L8HTwjFz+dkB9E/Sr XCpIh5AFVXwWCzrsLbPBuIenTKOwYv7vb3Cv3pPg1nfdJkJA+xgiYjxofA8VxXbBC7gedB2c Vb503C6ncoohU1eJ0b6N9PtfegNDccLx59tq/k0cDwWNB6R5qgM+NRAloKrQOjxb2LYeusRr CK9yRqA6s06tXigKDZQZcNRNqfqcgfMAupMXe9yDyLNBCX/Mdv+ybJoxvdgmg2nbJYpaYlx2 +MgJH5jSr0KPuJHaBxWTSuHvL5ngyHT6+CZW/CCAxwPhjRvge+1Qk6FIsnyZ59eDvZ95cVLZ XVsS1S3yT7wLnmFXZvXEr6BjT/bR/ig779xgicKIbop2i0hrFFjWAQ/5uQrGqn+Y04A9uCtV ZdLvzwGfl83NgZUiR/EyyIeFcqHXl2U34J+RXnGpM1aUfERk29kMpGCB2hLbf1S8AMx4to+L rR/x1YuOWuvJqQfdCwf5UTJm90mn9NUZStIYoSRKfxvQywZm8M9VFZLnQiiE31OIx678izPN jTur2eldvZCZV/PMEWwYKKTNbpMD3wLlVePylscFQ/3yV2KdWMOzN4qE15J+hN+H4aR6r+AF gZUO6yWnjymHf13lFFBvP9BfVHGQFbixPUKo956OTbHosorq6mtkBvPGqs2DrhyHJSIBWf1W 4siEJVs/kIHTrBhNus7BTQRMC5TtARAA88hJdpgcg2RU/uAWfAL46XZHA59cVpPNNly1tPWC SbG6+ONH6nOG/NarmNVxX6Mb9YRkEU6wmrZS85inz3otdyz/zlyNSWma8qGNUlMbiwFQqfXW VBAPGoRC0a0aJrd4IayLuvv1UqEwx7Otp7y5RNHtRv35/kho0Z+UheYVdGm2I06xIc+aNKW2 LO7R5BNtjpADPIG+NSdsVIeamhAWPvLrwbf6mUb//eA9pF0w0QixLVrH/cCoz+S27gCGJvY6 zF22NgdhnkIqNz8E/LKt6S36ZI9Mw/ixpQTozqRmdNzVQNgTHUZClbJj4iq1EPHB7XqpxOv+ awrxSxq2jt8GFD0rU+sAuzW+F7cBoIw434/IrxKYwcPHpHLEVQ1tLP7d3ZpZR30p3oqoliGi LsWvHHxyXjuMBF4XJ6MRXmD65/qOhuo2DKduHMNlmxzgSzvWgXZeNJq+OcS8jQZDt2Na2pMK jWytau7xQu2ndm0FwS48ngMrDYRQMxzL1NfnBnT9BCwjiU+/6NBSwcNKIqyea9IpTwsVfkF4 /iui7xD9+LtzqeUkBAe7q5jEJmJMZhAfh7usZGT8TGxXegCaF4Jwz2nxS4Fv7VRza/yUAOJl c0daR11TPeiUNCQWY7PpL1AXO9vaSyjFuOzTnU8vzXvI9fGoxIxKGRQpKMU8PROIFw0AEQEA AcLBXwQYAQIACQUCTAuU7QIbDAAKCRD3enNVkraaBIxXD/4xlaBwW2TLFfMvlcY/2XDSm6NO 4JaJG2Nzp35xaaBVwMVzWvI+GgTgKNSFot9f4jiLBNQdnq3UKoEThR2ORKVL0ZJS1QYR7yyr Oo0MteDSy8ofU1FJ6xu4ND3ekOjP20BTrihDpqUdahir2uaRfMkwM+0imOlcutGMhJNF/LAj rhoDp9SeDMYBXZ1wfrbrEo/EEu0PbkGyzqPyEPqwN1iSJkcAnjuIA0rTf1jQtJAaDov7yHsS RwUM+qTGsjOGQAN3wtYwjPpw7hI01sE+x0uq0pVeo4qeWTZ2TE4Vtp8FKXFAkqnP878q+kNk 9Ve+DRs8UlRfa9Lgf5ETjXOTVGaT/UGxi9B4oo8k0lzvM/A1txexL/lLw8AULhUeGtyS6D2X 9vFi6azna+o918R9BV86uXPiDOf1nMwqKchNCxmgH9vd0aQm8TKCrWAW4kU1Ig6aMNuZiWlo VZfKrmWizbgeGKE9rhNPNqxkqBaA4lrJ8L6bdKbhAOe3NQjO2vUAXB53JphlF74GwEsh+85i 9/yIbvwJVcsFYhdZz7fCAUOcnFkGnyrwIgkizQ3xXShPW8mqkgUk4kYMnucC4kG/E7pI/4lk e5X5X9vroXRHB7tkpAgT46SqSM/XTwCaseXG9orDgz3duRTUp6K0++S/qsqTakGVmjD5917A 1HqWfMmiKA== Organization: Secure Endpoints Inc. Message-ID: <46a37406-7dfe-b28e-de18-53224749ef50@secure-endpoints.com> Date: Tue, 4 Dec 2018 13:14:38 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040001070403090202010907" Archived-At: Subject: Re: [kitten] SPAKE channel ID for second-factor 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, 04 Dec 2018 18:14:48 -0000 This is a cryptographically signed message in MIME format. --------------ms040001070403090202010907 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 12/3/2018 1:40 PM, Greg Hudson wrote: > I have been thinking recently about some security properties of SPAKE > preauth with a second factor. SPAKE preauth leverages the first factor= > (the long-term key) to establish a channel, and then includes > second-factor communication in the key confirmation and perhaps in > subsequent messages. This design is consistent with the ancient SAM-2 > preauth mechanism (although much better because it uses a PAKE), but is= > different from typical modern multi-factor authentication which tends t= o > rely on a TLS channel (authenticated by server cert) to protect all > authentication factors. >=20 > A consequence of the SPAKE preauth design is that if an attacker knows > the first factor (say, because of password reuse), the attacker can MIT= M > the SPAKE exchange and relay the second-factor communication across the= > KDC-to-attacker and attacker-to-client channels, to obtain a KDC > response the attacker can decrypt. Hi Greg, My concern about the SPAKE design is that it enables the factors to be attacked independently. It is possible for the attacker to know that the long-term key is correct without being forced to use the second facto= r. I would really like to see our efforts be invested in a multi-factor Kerberos (not necessarily limited to two factors) where all of the factors must be consumed before an successful or failure can be determine= d. Does MIT have any interest in working on such a pre-auth mechanism? Thanks. Jeffrey Altman --------------ms040001070403090202010907 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DJowggYBMIIE6aADAgECAhBAAWafTz5dAElKUO3y42hlMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy MB4XDTE4MTAyMzA1MDQyMloXDTE5MTEwMzA1MDQyMlowgZUxNTAzBgNVBAsMLFZlcmlmaWVk IEVtYWlsOiBqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMSswKQYJKoZIhvcNAQkBFhxq YWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMS8wLQYKCZImiZPyLGQBARMfQTAxNDI3RTAw MDAwMTY2OUY0RjNFMjcwMDAwMzFGQjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AJTyhcbPAvKyN1Vs9gjMN6oYnNwvoje6fdgl1mlqAkeIjASHSt1rupAuwXDcTCNVo7k4veY3 bmY9/q32DigX84dt/a15AQDBYhuCn0b5KKTkxOFTq0feIg2NjTz5w4Qnl7fsycxOeJurQXKT wS655O4M3iGb0Y+txxCLwFfWD9p2TQ/nbZXmiCk0Kb+Zsd3IIMwpQ9JU9lSsQqIUzNZ+/3gE eY9oAz7gEWHiOxp/0rnR0DKSqVIS0e7kVhBXjJ59G8iCWMoeSNVy1iVBcLz2TUt8HsEVUPjI rsasYjbBt/PoHXZsNvJ/eN7I3KNiWf00ubf+4kzo92l31VJ/PkwEQNcCAwEAAaOCAqUwggKh MA4GA1UdDwEB/wQEAwIFoDCBhAYIKwYBBQUHAQEEeDB2MDAGCCsGAQUFBzABhiRodHRwOi8v Y29tbWVyY2lhbC5vY3NwLmlkZW50cnVzdC5jb20wQgYIKwYBBQUHMAKGNmh0dHA6Ly92YWxp ZGF0aW9uLmlkZW50cnVzdC5jb20vY2VydHMvdHJ1c3RpZGNhYTEyLnA3YzAfBgNVHSMEGDAW gBSkc9rvaTWKdcygGXsIMvhrieRC7DAJBgNVHRMEAjAAMIIBLAYDVR0gBIIBIzCCAR8wggEb BgtghkgBhvkvAAYLATCCAQowSgYIKwYBBQUHAgEWPmh0dHBzOi8vc2VjdXJlLmlkZW50cnVz dC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMIG7BggrBgEFBQcCAjCB rhqBq1RoaXMgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBoYXMgYmVlbiBpc3N1ZWQgaW4gYWNjb3Jk YW5jZSB3aXRoIApJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmljYXRlIFBvbGljeSBmb3Vu ZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kv dHMvaW5kZXguaHRtbDBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8vdmFsaWRhdGlvbi5pZGVu dHJ1c3QuY29tL2NybC90cnVzdGlkY2FhMTIuY3JsMCcGA1UdEQQgMB6BHGphbHRtYW5Ac2Vj dXJlLWVuZHBvaW50cy5jb20wHQYDVR0OBBYEFJdlICa5IVm/mQsa1LIql1jf/0BXMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAvSWHh+2vqTbu 65C4E+eXKv9Wz5LzqJNGWbkMq0a4/LswbvpWgG3AmFqeWXmbjfoFxWjnltt4mAYH2s/YCE9X 74kc7TXcRW+GKLGbazW2v/gffBYHudxjtIJRvQpcsiqqYRI0eVCer3kRdAPuEYz+62y1CACP qwvaNo4fSHCSEqLDglgxFw7bNs0xV4Fb0yw4L4bv1zsnT6hrNQ4ibJEqQ7Ciq1sDRAGc4SmV P9I0rbCV6mYlxxOEvvUPFfppp4/YAKTLtXuzB+QeTW8fR1HvVbRZitnvTEBVP8ChDwhlj6NA l16ZeJWeo+Wru3Lv4HCV2PuKyJjKoFYyr6Y3GjZ3ZzCCBpEwggR5oAMCAQICEQD53lZ/yU0M d3D5YBtS2hU7MA0GCSqGSIb3DQEBCwUAMEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVu VHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVzdCBDb21tZXJjaWFsIFJvb3QgQ0EgMTAeFw0xNTAy MTgyMjI1MTlaFw0yMzAyMTgyMjI1MTlaMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVu VHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA0ZFNPM8KJzSSrkvpmtQla3ksT+fq1s9c+Ea3YSC/umUkygSm9UkkOoaoNjKZ oCx3wef1kwC4pQQV2XHk+AKR+7uMvnOCIw2cAVUP0/Kuy4X6miqaXGGVDTqwVjaFuFCRVVDT QoI2BTMpwFQi+O/TjD5+E0+TAZbkzsB7krk4YUbA6hFyT0YboxRUq9M2QHDb+80w53b1UZVO 1HS2Mfk9LnINeyzjxiXU/iENK07YvjBOxbY/ftAYPbv/9cY3wrpqZYHoXZc6B9/8+aVCNA45 FP3k+YuTDC+ZrmePQBLQJWnyS/QrZEdXsaieWUqkUMxPQKTExArCiP61YRYlOIMpKwIDAQAB o4ICgDCCAnwwgYkGCCsGAQUFBwEBBH0wezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNp YWwub2NzcC5pZGVudHJ1c3QuY29tMEcGCCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5p ZGVudHJ1c3QuY29tL3Jvb3RzL2NvbW1lcmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTt RBnA0/AGi+6ke75C5yZUyI42djAPBgNVHRMBAf8EBTADAQH/MIIBIAYDVR0gBIIBFzCCARMw ggEPBgRVHSAAMIIBBTCCAQEGCCsGAQUFBwICMIH0MEUWPmh0dHBzOi8vc2VjdXJlLmlkZW50 cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMAMCAQEagapUaGlz IFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJlZW4gaXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0 aCBJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRw czovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXgu aHRtbDBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29t L2NybC9jb21tZXJjaWFscm9vdGNhMS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUpHPa72k1inXMoBl7CDL4a4nkQuwwDQYJ KoZIhvcNAQELBQADggIBAA3hgq7S+/TrYxl+D7ExI1Rdgq8fC9kiT7ofWlSaK/IMjgjoDfBb PGWvzdkmbSgYgXo8GxuAon9+HLIjNv68BgUmbIjwj/SYaVz6chA25XZdjxzKk+hUkqCmfOn/ twQJeRfxHg3I+0Sfwp5xs10YF0RobhrsCRne6OUmh9mph0fE3b21k90OVnx9Hfr+YAV4ISrT A6045zQTKGzb370whliPLFo+hNL6XzEty5hfdFaWKtHIfpE994CLmTJI4SEbWq40d7TpAjCm KCPIVPq/+9GqggGvtakM5K3VXNc9VtKPU9xYGCTDIYoeVBQ65JsdsdyM4PzDzAdINsv4vaF7 yE03nh2jLV7XAkcqad9vS4EB4hKjFFsmcwxa+ACUfkVWtBaWBqN4f/o1thsFJHEAu4Q6oRB6 mYkzqrPigPazF2rgYw3lp0B1gSzCRj+jRtErIVdMPeZ2p5Fdx7SNhBtabuhqmpJkFxwW9SBg 6sHvy0HpzVvEiBpApFKG1ZHXMwzQl+pR8P27wWDsblJU7Qgb8ZzGRK9l5GOFhxtN+oXZ4CCm unLMtaZ2vSai7du/VKrg64GGZNAKerEBevjJVNFgeSnmUK9GB4kCZ7U5NWlU+2H87scntW4Q /0Y6vqQJcJeaMHg/dQnahTQ2p+hB1xJJK32GWIAucTFMSOKLbQHadIOiMYIDFDCCAxACAQEw TjA6MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElE IENBIEExMgIQQAFmn08+XQBJSlDt8uNoZTANBglghkgBZQMEAgEFAKCCAZcwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgxMjA0MTgxNDM4WjAvBgkqhkiG 9w0BCQQxIgQgWpOj8U3ukRJYtTIpvgs0pcobwoMOlUoXPzTTRPz/IUIwXQYJKwYBBAGCNxAE MVAwTjA6MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVz dElEIENBIEExMgIQQAFmn08+XQBJSlDt8uNoZTBfBgsqhkiG9w0BCRACCzFQoE4wOjELMAkG A1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTIC EEABZp9PPl0ASUpQ7fLjaGUwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQBq8V9ieVlcaAdSDozuIR74 KDZGBKyWPPtcTpKfXJ/sa3TVtfEX8qMW7DpOeBWVj0jSKEL+++LEunrz/3cd6C89k65TvFDj lCbwqy1stLGeC0/bV09MegZEvC4LnDnl63xSgUrQa/Qh48Uh+TKBKEc/YVcsxXHFAIhlYpJG TbqkCgL6oh+TdGdVKzQLoKMTwlS16wNiT6Y86WWcdotChPOpxLYfYmQu+H+stnPL/g+w27PO iTXE/pcZVgZL1/SfDKKHiZJ5yJE8jn01tsfKKJ21TxUV/kolzjAvDljDFbpdRPUZGYoajAKB sKhThNCxDRUV15igNZWq3SPuTWOXpMg9AAAAAAAA --------------ms040001070403090202010907-- From nobody Tue Dec 4 10:31:43 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40616130F29 for ; Tue, 4 Dec 2018 10:31:41 -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 oNbOfxNWK1YD for ; Tue, 4 Dec 2018 10:31:39 -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 3E992130EEC for ; Tue, 4 Dec 2018 10:31:39 -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 B460F2D7FB; Tue, 4 Dec 2018 18:31:38 +0000 (UTC) Received: from ovpn-116-70.phx2.redhat.com (ovpn-116-70.phx2.redhat.com [10.3.116.70]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 48D025C21C; Tue, 4 Dec 2018 18:31:38 +0000 (UTC) Message-ID: From: Simo Sorce To: Jeffrey Altman , Greg Hudson , kitten@ietf.org Date: Tue, 04 Dec 2018 13:31:37 -0500 In-Reply-To: <46a37406-7dfe-b28e-de18-53224749ef50@secure-endpoints.com> References: <46a37406-7dfe-b28e-de18-53224749ef50@secure-endpoints.com> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Tue, 04 Dec 2018 18:31:38 +0000 (UTC) Archived-At: Subject: Re: [kitten] SPAKE channel ID for second-factor 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, 04 Dec 2018 18:31:41 -0000 On Tue, 2018-12-04 at 13:14 -0500, Jeffrey Altman wrote: > On 12/3/2018 1:40 PM, Greg Hudson wrote: > > I have been thinking recently about some security properties of SPAKE > > preauth with a second factor. SPAKE preauth leverages the first factor > > (the long-term key) to establish a channel, and then includes > > second-factor communication in the key confirmation and perhaps in > > subsequent messages. This design is consistent with the ancient SAM-2 > > preauth mechanism (although much better because it uses a PAKE), but is > > different from typical modern multi-factor authentication which tends to > > rely on a TLS channel (authenticated by server cert) to protect all > > authentication factors. > > > > A consequence of the SPAKE preauth design is that if an attacker knows > > the first factor (say, because of password reuse), the attacker can MITM > > the SPAKE exchange and relay the second-factor communication across the > > KDC-to-attacker and attacker-to-client channels, to obtain a KDC > > response the attacker can decrypt. > > Hi Greg, > > My concern about the SPAKE design is that it enables the factors to be > attacked independently. It is possible for the attacker to know that > the long-term key is correct without being forced to use the second factor. > > I would really like to see our efforts be invested in a multi-factor > Kerberos (not necessarily limited to two factors) where all of the > factors must be consumed before an successful or failure can be determined. > > Does MIT have any interest in working on such a pre-auth mechanism? If the factors are known in advance you could combined multiple of them and use them instead of the single long term key as the spake secret. It just makes the multiple factors non optional, so it is a harder user experience. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc From nobody Tue Dec 4 11:42:32 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF252129C6B for ; Tue, 4 Dec 2018 11:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUD59I4ZvUKr for ; Tue, 4 Dec 2018 11:42:28 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48A2C12875B for ; Tue, 4 Dec 2018 11:42:28 -0800 (PST) X-AuditID: 1209190d-10d579e000000ef1-87-5c06d8a2709e Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 79.BF.03825.2A8D60C5; Tue, 4 Dec 2018 14:42:26 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.14.7/8.9.2) with ESMTP id wB4Jb1jp011905; Tue, 4 Dec 2018 14:37:11 -0500 Received: from [18.101.8.143] (VPN-18-101-8-143.MIT.EDU [18.101.8.143]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wB4JavYn029148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 4 Dec 2018 14:37:00 -0500 To: Jeffrey Altman , kitten@ietf.org References: <46a37406-7dfe-b28e-de18-53224749ef50@secure-endpoints.com> From: Greg Hudson Message-ID: Date: Tue, 4 Dec 2018 14:36:57 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <46a37406-7dfe-b28e-de18-53224749ef50@secure-endpoints.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixG6nrrvoBluMwfnX1hZ/Vk5iszi6eRWL A5PHkiU/mTxO9p1nDWCK4rJJSc3JLEst0rdL4MqYfM6w4CpbxaHz+1kbGNezdjFyckgImEj8 330WyObiEBJYwyTxZX8XI4SzgVHi6MdVUJkjTBJzb20BaxEWsJC4tfgBO4gtIuAkMXvhabC4 kECyxOU9O8HibALKEuv3b2UBsXkFrCT23PrLDGKzCKhIrN28ixHEFhWIkLh3/hMbRI2gxMmZ T8DqOQU8JLYePgw2h1nATGLe5ofMELa4xK0n85kgbHmJ7W/nME9gFJiFpH0WkpZZSFpmIWlZ wMiyilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdILzezRC81pXQTIyiAOSV5dzD+u+t1iFGAg1GJ h1diCluMEGtiWXFl7iFGSQ4mJVHeDWpAIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8d0ByvCmJ lVWpRfkwKWkOFiVx3t8ij6OFBNITS1KzU1MLUotgsjIcHEoSvPmXgBoFi1LTUyvSMnNKENJM HJwgw3mAhgudBRleXJCYW5yZDpE/xagoJc6rfA4oIQCSyCjNg+sFJ5hUjv5XjOJArwjz1lwH quIBJie47ldAg5mABudsYQIZXJKIkJJqYNRgWXyEIXFL0dK0L/yPTM9xBnQ2PrF7sLFFJN/5 dNV7V43oB7+nrXk4K0iN/VKqTOg89uqa3qO6XT/cNwstXfFOe8MCp/kRN/fqHLun2Xl8rYRW vZeb7ZEbJ+Q3O8Tn9W+arvbjjPb8O+9sPhz7uvT23N5XZ3NX+Wl93vUgQ4djBff8ldNcZZqV WIozEg21mIuKEwEdQZ48CwMAAA== Archived-At: Subject: Re: [kitten] SPAKE channel ID for second-factor 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, 04 Dec 2018 19:42:30 -0000 On 12/04/2018 01:14 PM, Jeffrey Altman wrote: > My concern about the SPAKE design is that it enables the factors to be > attacked independently. It is possible for the attacker to know that > the long-term key is correct without being forced to use the second factor. The draft talks about this in the security considerations; see the discussion of "indistinguishability" in the subsection on side channels. The SPAKE design can support indistinguishability if the second factor uses only a single round trip, and if the KDC implementation is careful to avoid timing channels. (Unless the authors have missed something in our analysis, and there's an easy way for an attacker to know whether the guessed long-term key is correct even under the above constraints. But in that case you'll have to point out what we've missed.) From nobody Tue Dec 4 11:56:03 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985A2130E3B for ; Tue, 4 Dec 2018 11:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8rjtttZnomg for ; Tue, 4 Dec 2018 11:55:59 -0800 (PST) Received: from lavender.maple.relay.mailchannels.net (lavender.maple.relay.mailchannels.net [23.83.214.99]) (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 5321712F1AB for ; Tue, 4 Dec 2018 11:55:59 -0800 (PST) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 8D19843AEC; Tue, 4 Dec 2018 19:55:55 +0000 (UTC) Received: from pdx1-sub0-mail-a26.g.dreamhost.com (unknown [100.96.19.78]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id D670943B71; Tue, 4 Dec 2018 19:55:54 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a26.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Tue, 04 Dec 2018 19:55:55 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Abaft-Arch: 700a2b0020755e8f_1543953355196_1138617870 X-MC-Loop-Signature: 1543953355196:171860134 X-MC-Ingress-Time: 1543953355195 Received: from pdx1-sub0-mail-a26.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a26.g.dreamhost.com (Postfix) with ESMTP id 55FFA7FB3F; Tue, 4 Dec 2018 11:55:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=uZcq4YJUl5B7P3 SfJfNhv+vg6Xs=; b=HNoOSv82PohTEcnux57YSsmx1NZP8LGEkFXGHAawnYGpMH q8oQ7HZWKKLNK6eedBPtHIA9xjepUMKU4X2z3RipPemODwq0oS0fjxvSHUpO5C5P Rb/TrX1AywU2lLKR+F5D330YovDAZvu4yF/fbbu9694SqCUR/6BHpJ7Kb7mfA= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a26.g.dreamhost.com (Postfix) with ESMTPSA id D15867FB3B; Tue, 4 Dec 2018 11:55:52 -0800 (PST) Date: Tue, 4 Dec 2018 13:55:50 -0600 X-DH-BACKEND: pdx1-sub0-mail-a26 From: Nico Williams To: Jeffrey Altman Cc: Greg Hudson , kitten@ietf.org Message-ID: <20181204195549.GN15561@localhost> References: <46a37406-7dfe-b28e-de18-53224749ef50@secure-endpoints.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46a37406-7dfe-b28e-de18-53224749ef50@secure-endpoints.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrudeffedgudefudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [kitten] SPAKE channel ID for second-factor 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, 04 Dec 2018 19:56:02 -0000 On Tue, Dec 04, 2018 at 01:14:38PM -0500, Jeffrey Altman wrote: > My concern about the SPAKE design is that it enables the factors to be > attacked independently. It is possible for the attacker to know that > the long-term key is correct without being forced to use the second factor. If the second factor requires just one round trip, then this SPAKE PA does not leak which of the two (or both) failed. Second factors that require more than one round trip can only continue when the first factor passes, so in that case there is a leak. > I would really like to see our efforts be invested in a multi-factor > Kerberos (not necessarily limited to two factors) where all of the > factors must be consumed before an successful or failure can be determined. For non-key generating second factors, the only way to do this is to exchange all the factors independently under the protection of a FAST armor ticket. FAST kinda provides for a second factor, but not very well. This could be improved, I suppose. Nico -- From nobody Tue Dec 4 13:27:44 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD15130DC4 for ; Tue, 4 Dec 2018 13:27:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=secure-endpoints.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 N0DQ07MopScr for ; Tue, 4 Dec 2018 13:27:39 -0800 (PST) Received: from sequoia-grove.secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4C3712D4E8 for ; Tue, 4 Dec 2018 13:27:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/relaxed; d=secure-endpoints.com; s=MDaemon; t=1543958857; x=1544563657; i=jaltman@secure-endpoints.com; q=dns/txt; h=VBR-Info:Subject:To: References:From:Openpgp:Autocrypt:Organization:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type; bh=MDFb+aWT+6R UnejwXHeaetx72WmA2E0+0+CTSrdRB0Q=; b=VF6DDMlUARZKkyScXhfTMiFF6sz u+a+lWHhlmZ7eHgiXev3Gn3XsdApeWPP6RFUTm9KoOEzJa/z6B6RE7SpRcMk5UEw VEh6DcyPeh+FhtXStQKPQzk7njXUNjLHatXDen8ccA45sfgOj3vza7kUWLP3uHYu BJCCo3ARptRHQiWs= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Tue, 04 Dec 2018 16:27:37 -0500 X-Spam-Processed: sequoia-grove.secure-endpoints.com, Tue, 04 Dec 2018 16:27:37 -0500 Received: from [IPv6:2001:470:1f07:f77:f852:c1fb:ffa6:d6c0] by secure-endpoints.com (IPv6:2001:470:1f07:f77:28d9:68fb:855d:c2a5) (MDaemon PRO v18.5.1) with ESMTPSA id md50001770787.msg; Tue, 04 Dec 2018 16:27:36 -0500 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-MDRemoteIP: 2001:470:1f07:f77:f852:c1fb:ffa6:d6c0 X-MDHelo: [IPv6:2001:470:1f07:f77:f852:c1fb:ffa6:d6c0] X-MDArrival-Date: Tue, 04 Dec 2018 16:27:36 -0500 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=1876b0ebb2=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org X-CAV-Result: clean To: Simo Sorce , Greg Hudson , kitten@ietf.org References: <46a37406-7dfe-b28e-de18-53224749ef50@secure-endpoints.com> From: Jeffrey Altman Openpgp: id=FA444AF197F449B24CF3E699F77A735592B69A04; url=https://pgp.mit.edu Autocrypt: addr=jaltman@secure-endpoints.com; prefer-encrypt=mutual; keydata= xsFNBEwLlO0BEACu6yWFkd1+qwsGg8ZzgslSkcAKhSegWt5j86DpaRL0W8fxg6YjxwEPvwoH BGa/rpSdBd1gkmzeYxD3hVZdj75r6nVS9f/mxNQzW+o1sW4vaeSxKgZSQz5RqHmwPDcqQP66 +ZSnjV+G88MKwZ9DIzA9AwpJhNAAlAlj3OvsQVsxd1ipc6C4/U3qjHL7Ih22UbPBM71ltIZx kqcrAlXPnUTeraJXtfzYbq4mJFJ9JC6/o1NRSjsBvRD+ADxlG50+KccZN4SS5xxdGuh1tA9U TydYBQB3YtJbq7CYau2kIYt/3HnyLYGo1s6Ti6cuAJJ/40iIE1xkqhvMiIz/Q+1ztmksJbLQ aCtW8kF42nF8MpPdIPTSPr2uGvpRtCjRbh4lgMXgyNUx1wpCEY0X11xce++H8HySmFwryE2y kkxUQeMUjaaXZDHYUSyQz7riChFiZ9ax9dmX0wUY/A05v0qcualglpk4wJ2kcsGKUEGkLvnV wwvya8zifPwKOw5JlGPvzX8t2m7jB2GXKzvVAsImqOqnDBTKUXWQQZCW9Rqt7acdE8bQ2vqr vP+3Ykf4SrPwcuNCDt6QSgjVbhc3hA3hCtE1iW/HhuBAzKiuzJ9era+q9QjTtLPIkQDHRpcC MMWvK0Y1uQ34Ql1BfKRA4gc8A7CuVUY6+Ga7PuJWd+FSglvmKQARAQABzS1KZWZmcmV5IEFs dG1hbiA8amFsdG1hbkB5b3VyLWZpbGUtc3lzdGVtLmNvbT7CwXkEEwECACMCGyMGCwkIBwMC BBUCCAMEFgIDAQIeAQIXgAUCTAuXLQIZAQAKCRD3enNVkraaBJDnD/9L8HTwjFz+dkB9E/Sr XCpIh5AFVXwWCzrsLbPBuIenTKOwYv7vb3Cv3pPg1nfdJkJA+xgiYjxofA8VxXbBC7gedB2c Vb503C6ncoohU1eJ0b6N9PtfegNDccLx59tq/k0cDwWNB6R5qgM+NRAloKrQOjxb2LYeusRr CK9yRqA6s06tXigKDZQZcNRNqfqcgfMAupMXe9yDyLNBCX/Mdv+ybJoxvdgmg2nbJYpaYlx2 +MgJH5jSr0KPuJHaBxWTSuHvL5ngyHT6+CZW/CCAxwPhjRvge+1Qk6FIsnyZ59eDvZ95cVLZ XVsS1S3yT7wLnmFXZvXEr6BjT/bR/ig779xgicKIbop2i0hrFFjWAQ/5uQrGqn+Y04A9uCtV ZdLvzwGfl83NgZUiR/EyyIeFcqHXl2U34J+RXnGpM1aUfERk29kMpGCB2hLbf1S8AMx4to+L rR/x1YuOWuvJqQfdCwf5UTJm90mn9NUZStIYoSRKfxvQywZm8M9VFZLnQiiE31OIx678izPN jTur2eldvZCZV/PMEWwYKKTNbpMD3wLlVePylscFQ/3yV2KdWMOzN4qE15J+hN+H4aR6r+AF gZUO6yWnjymHf13lFFBvP9BfVHGQFbixPUKo956OTbHosorq6mtkBvPGqs2DrhyHJSIBWf1W 4siEJVs/kIHTrBhNus7BTQRMC5TtARAA88hJdpgcg2RU/uAWfAL46XZHA59cVpPNNly1tPWC SbG6+ONH6nOG/NarmNVxX6Mb9YRkEU6wmrZS85inz3otdyz/zlyNSWma8qGNUlMbiwFQqfXW VBAPGoRC0a0aJrd4IayLuvv1UqEwx7Otp7y5RNHtRv35/kho0Z+UheYVdGm2I06xIc+aNKW2 LO7R5BNtjpADPIG+NSdsVIeamhAWPvLrwbf6mUb//eA9pF0w0QixLVrH/cCoz+S27gCGJvY6 zF22NgdhnkIqNz8E/LKt6S36ZI9Mw/ixpQTozqRmdNzVQNgTHUZClbJj4iq1EPHB7XqpxOv+ awrxSxq2jt8GFD0rU+sAuzW+F7cBoIw434/IrxKYwcPHpHLEVQ1tLP7d3ZpZR30p3oqoliGi LsWvHHxyXjuMBF4XJ6MRXmD65/qOhuo2DKduHMNlmxzgSzvWgXZeNJq+OcS8jQZDt2Na2pMK jWytau7xQu2ndm0FwS48ngMrDYRQMxzL1NfnBnT9BCwjiU+/6NBSwcNKIqyea9IpTwsVfkF4 /iui7xD9+LtzqeUkBAe7q5jEJmJMZhAfh7usZGT8TGxXegCaF4Jwz2nxS4Fv7VRza/yUAOJl c0daR11TPeiUNCQWY7PpL1AXO9vaSyjFuOzTnU8vzXvI9fGoxIxKGRQpKMU8PROIFw0AEQEA AcLBXwQYAQIACQUCTAuU7QIbDAAKCRD3enNVkraaBIxXD/4xlaBwW2TLFfMvlcY/2XDSm6NO 4JaJG2Nzp35xaaBVwMVzWvI+GgTgKNSFot9f4jiLBNQdnq3UKoEThR2ORKVL0ZJS1QYR7yyr Oo0MteDSy8ofU1FJ6xu4ND3ekOjP20BTrihDpqUdahir2uaRfMkwM+0imOlcutGMhJNF/LAj rhoDp9SeDMYBXZ1wfrbrEo/EEu0PbkGyzqPyEPqwN1iSJkcAnjuIA0rTf1jQtJAaDov7yHsS RwUM+qTGsjOGQAN3wtYwjPpw7hI01sE+x0uq0pVeo4qeWTZ2TE4Vtp8FKXFAkqnP878q+kNk 9Ve+DRs8UlRfa9Lgf5ETjXOTVGaT/UGxi9B4oo8k0lzvM/A1txexL/lLw8AULhUeGtyS6D2X 9vFi6azna+o918R9BV86uXPiDOf1nMwqKchNCxmgH9vd0aQm8TKCrWAW4kU1Ig6aMNuZiWlo VZfKrmWizbgeGKE9rhNPNqxkqBaA4lrJ8L6bdKbhAOe3NQjO2vUAXB53JphlF74GwEsh+85i 9/yIbvwJVcsFYhdZz7fCAUOcnFkGnyrwIgkizQ3xXShPW8mqkgUk4kYMnucC4kG/E7pI/4lk e5X5X9vroXRHB7tkpAgT46SqSM/XTwCaseXG9orDgz3duRTUp6K0++S/qsqTakGVmjD5917A 1HqWfMmiKA== Organization: Secure Endpoints Inc. Message-ID: Date: Tue, 4 Dec 2018 16:27:30 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040202030006060402010403" Archived-At: Subject: Re: [kitten] SPAKE channel ID for second-factor 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, 04 Dec 2018 21:27:43 -0000 This is a cryptographically signed message in MIME format. --------------ms040202030006060402010403 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 12/4/2018 1:31 PM, Simo Sorce wrote: > If the factors are known in advance you could combined multiple of them= > and use them instead of the single long term key as the spake secret. >=20 > It just makes the multiple factors non optional, so it is a harder user= > experience. Hi Simo, =46rom a practical perspective, separate Kerberos principals must be associated with different proofs of identity in order for applications to be able to make authorization decisions UNLESS authorization data is assigned to the ticket by the KDC based upon the proofs. However, issuing tickets with varying authorization data is dangerous because of credential caching and the impact on cross-realm ticket issuance. Separate credentials might be required for john.doe@REALM long-term key only john.doe/duo@REALM long-term key plus duo john.doe/piv@REALM PIV card john.doe/cac@REALM CAC card etc. One user might have two or three of the above. Therefore, I do not consider the optional factors case to be particularly interesting. Thanks. Jeffrey Altman --------------ms040202030006060402010403 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DJowggYBMIIE6aADAgECAhBAAWafTz5dAElKUO3y42hlMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy MB4XDTE4MTAyMzA1MDQyMloXDTE5MTEwMzA1MDQyMlowgZUxNTAzBgNVBAsMLFZlcmlmaWVk IEVtYWlsOiBqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMSswKQYJKoZIhvcNAQkBFhxq YWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMS8wLQYKCZImiZPyLGQBARMfQTAxNDI3RTAw MDAwMTY2OUY0RjNFMjcwMDAwMzFGQjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AJTyhcbPAvKyN1Vs9gjMN6oYnNwvoje6fdgl1mlqAkeIjASHSt1rupAuwXDcTCNVo7k4veY3 bmY9/q32DigX84dt/a15AQDBYhuCn0b5KKTkxOFTq0feIg2NjTz5w4Qnl7fsycxOeJurQXKT wS655O4M3iGb0Y+txxCLwFfWD9p2TQ/nbZXmiCk0Kb+Zsd3IIMwpQ9JU9lSsQqIUzNZ+/3gE eY9oAz7gEWHiOxp/0rnR0DKSqVIS0e7kVhBXjJ59G8iCWMoeSNVy1iVBcLz2TUt8HsEVUPjI rsasYjbBt/PoHXZsNvJ/eN7I3KNiWf00ubf+4kzo92l31VJ/PkwEQNcCAwEAAaOCAqUwggKh MA4GA1UdDwEB/wQEAwIFoDCBhAYIKwYBBQUHAQEEeDB2MDAGCCsGAQUFBzABhiRodHRwOi8v Y29tbWVyY2lhbC5vY3NwLmlkZW50cnVzdC5jb20wQgYIKwYBBQUHMAKGNmh0dHA6Ly92YWxp ZGF0aW9uLmlkZW50cnVzdC5jb20vY2VydHMvdHJ1c3RpZGNhYTEyLnA3YzAfBgNVHSMEGDAW gBSkc9rvaTWKdcygGXsIMvhrieRC7DAJBgNVHRMEAjAAMIIBLAYDVR0gBIIBIzCCAR8wggEb BgtghkgBhvkvAAYLATCCAQowSgYIKwYBBQUHAgEWPmh0dHBzOi8vc2VjdXJlLmlkZW50cnVz dC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMIG7BggrBgEFBQcCAjCB rhqBq1RoaXMgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBoYXMgYmVlbiBpc3N1ZWQgaW4gYWNjb3Jk YW5jZSB3aXRoIApJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmljYXRlIFBvbGljeSBmb3Vu ZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kv dHMvaW5kZXguaHRtbDBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8vdmFsaWRhdGlvbi5pZGVu dHJ1c3QuY29tL2NybC90cnVzdGlkY2FhMTIuY3JsMCcGA1UdEQQgMB6BHGphbHRtYW5Ac2Vj dXJlLWVuZHBvaW50cy5jb20wHQYDVR0OBBYEFJdlICa5IVm/mQsa1LIql1jf/0BXMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAvSWHh+2vqTbu 65C4E+eXKv9Wz5LzqJNGWbkMq0a4/LswbvpWgG3AmFqeWXmbjfoFxWjnltt4mAYH2s/YCE9X 74kc7TXcRW+GKLGbazW2v/gffBYHudxjtIJRvQpcsiqqYRI0eVCer3kRdAPuEYz+62y1CACP qwvaNo4fSHCSEqLDglgxFw7bNs0xV4Fb0yw4L4bv1zsnT6hrNQ4ibJEqQ7Ciq1sDRAGc4SmV P9I0rbCV6mYlxxOEvvUPFfppp4/YAKTLtXuzB+QeTW8fR1HvVbRZitnvTEBVP8ChDwhlj6NA l16ZeJWeo+Wru3Lv4HCV2PuKyJjKoFYyr6Y3GjZ3ZzCCBpEwggR5oAMCAQICEQD53lZ/yU0M d3D5YBtS2hU7MA0GCSqGSIb3DQEBCwUAMEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVu VHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVzdCBDb21tZXJjaWFsIFJvb3QgQ0EgMTAeFw0xNTAy MTgyMjI1MTlaFw0yMzAyMTgyMjI1MTlaMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVu VHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA0ZFNPM8KJzSSrkvpmtQla3ksT+fq1s9c+Ea3YSC/umUkygSm9UkkOoaoNjKZ oCx3wef1kwC4pQQV2XHk+AKR+7uMvnOCIw2cAVUP0/Kuy4X6miqaXGGVDTqwVjaFuFCRVVDT QoI2BTMpwFQi+O/TjD5+E0+TAZbkzsB7krk4YUbA6hFyT0YboxRUq9M2QHDb+80w53b1UZVO 1HS2Mfk9LnINeyzjxiXU/iENK07YvjBOxbY/ftAYPbv/9cY3wrpqZYHoXZc6B9/8+aVCNA45 FP3k+YuTDC+ZrmePQBLQJWnyS/QrZEdXsaieWUqkUMxPQKTExArCiP61YRYlOIMpKwIDAQAB o4ICgDCCAnwwgYkGCCsGAQUFBwEBBH0wezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNp YWwub2NzcC5pZGVudHJ1c3QuY29tMEcGCCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5p ZGVudHJ1c3QuY29tL3Jvb3RzL2NvbW1lcmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTt RBnA0/AGi+6ke75C5yZUyI42djAPBgNVHRMBAf8EBTADAQH/MIIBIAYDVR0gBIIBFzCCARMw ggEPBgRVHSAAMIIBBTCCAQEGCCsGAQUFBwICMIH0MEUWPmh0dHBzOi8vc2VjdXJlLmlkZW50 cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMAMCAQEagapUaGlz IFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJlZW4gaXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0 aCBJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRw czovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXgu aHRtbDBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29t L2NybC9jb21tZXJjaWFscm9vdGNhMS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUpHPa72k1inXMoBl7CDL4a4nkQuwwDQYJ KoZIhvcNAQELBQADggIBAA3hgq7S+/TrYxl+D7ExI1Rdgq8fC9kiT7ofWlSaK/IMjgjoDfBb PGWvzdkmbSgYgXo8GxuAon9+HLIjNv68BgUmbIjwj/SYaVz6chA25XZdjxzKk+hUkqCmfOn/ twQJeRfxHg3I+0Sfwp5xs10YF0RobhrsCRne6OUmh9mph0fE3b21k90OVnx9Hfr+YAV4ISrT A6045zQTKGzb370whliPLFo+hNL6XzEty5hfdFaWKtHIfpE994CLmTJI4SEbWq40d7TpAjCm KCPIVPq/+9GqggGvtakM5K3VXNc9VtKPU9xYGCTDIYoeVBQ65JsdsdyM4PzDzAdINsv4vaF7 yE03nh2jLV7XAkcqad9vS4EB4hKjFFsmcwxa+ACUfkVWtBaWBqN4f/o1thsFJHEAu4Q6oRB6 mYkzqrPigPazF2rgYw3lp0B1gSzCRj+jRtErIVdMPeZ2p5Fdx7SNhBtabuhqmpJkFxwW9SBg 6sHvy0HpzVvEiBpApFKG1ZHXMwzQl+pR8P27wWDsblJU7Qgb8ZzGRK9l5GOFhxtN+oXZ4CCm unLMtaZ2vSai7du/VKrg64GGZNAKerEBevjJVNFgeSnmUK9GB4kCZ7U5NWlU+2H87scntW4Q /0Y6vqQJcJeaMHg/dQnahTQ2p+hB1xJJK32GWIAucTFMSOKLbQHadIOiMYIDFDCCAxACAQEw TjA6MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElE IENBIEExMgIQQAFmn08+XQBJSlDt8uNoZTANBglghkgBZQMEAgEFAKCCAZcwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgxMjA0MjEyNzMwWjAvBgkqhkiG 9w0BCQQxIgQgxh7mb1qlOOlOaZNbTbfs1EAZxD31KxCkq9YaCD2fKOIwXQYJKwYBBAGCNxAE MVAwTjA6MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVz dElEIENBIEExMgIQQAFmn08+XQBJSlDt8uNoZTBfBgsqhkiG9w0BCRACCzFQoE4wOjELMAkG A1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTIC EEABZp9PPl0ASUpQ7fLjaGUwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQAmeVJEFeRzV2NJxRzx6vcH +8CERJEbdffX3jX5h5/zOxbEDX8VP2F7uPtqEbVrDfEOn87ASfpohCuiSWlcvnl3GPxIj2Jf wsFpOl11hhNCh5QAW5P4KJ/iErcOEWpCgGNsMhH5jsxbzw3oYYRwejGzpWXkfhl4gIiNjq/A ORK9EYTfpSjCyA0mFfqGOMKDnwmn/hHWUY8H3c1FWjG5OkUSe/L8BRfU691ZW04h1fqEFrQ0 9x4/S/CJ+w2yBDo8PdYAIppm3cR+49FJ1/gozHaVJ8ig0eJneS18Dv+qpdg6yJGvAX7Z7OQI mxEkTsxwcrb1chcqiyAzoLsb7bU+w6ZYAAAAAAAA --------------ms040202030006060402010403-- From nobody Tue Dec 4 15:07:12 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A6F130F0A for ; Tue, 4 Dec 2018 15:07:11 -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 1YJTT6g5aV-2 for ; Tue, 4 Dec 2018 15:07:09 -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 516BD130EEE for ; Tue, 4 Dec 2018 15:07:09 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D1B813082A44; Tue, 4 Dec 2018 23:07:08 +0000 (UTC) Received: from ovpn-116-70.phx2.redhat.com (ovpn-116-70.phx2.redhat.com [10.3.116.70]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 69D8319492; Tue, 4 Dec 2018 23:07:08 +0000 (UTC) Message-ID: From: Simo Sorce To: Jeffrey Altman , Greg Hudson , kitten@ietf.org Date: Tue, 04 Dec 2018 18:07:07 -0500 In-Reply-To: References: <46a37406-7dfe-b28e-de18-53224749ef50@secure-endpoints.com> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.45]); Tue, 04 Dec 2018 23:07:08 +0000 (UTC) Archived-At: Subject: Re: [kitten] SPAKE channel ID for second-factor 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, 04 Dec 2018 23:07:11 -0000 On Tue, 2018-12-04 at 16:27 -0500, Jeffrey Altman wrote: > On 12/4/2018 1:31 PM, Simo Sorce wrote: > > If the factors are known in advance you could combined multiple of them > > and use them instead of the single long term key as the spake secret. > > > > It just makes the multiple factors non optional, so it is a harder user > > experience. > > Hi Simo, > > From a practical perspective, separate Kerberos principals must be > associated with different proofs of identity in order for applications > to be able to make authorization decisions UNLESS authorization data is > assigned to the ticket by the KDC based upon the proofs. Indeed we have the Authentication Indicator data that expresses exactly this idea. > However, > issuing tickets with varying authorization data is dangerous because of > credential caching and the impact on cross-realm ticket issuance. This is a valid concern. > Separate credentials might be required for > > john.doe@REALM long-term key only > john.doe/duo@REALM long-term key plus duo > john.doe/piv@REALM PIV card > john.doe/cac@REALM CAC card > > etc. One user might have two or three of the above. > > Therefore, I do not consider the optional factors case to be > particularly interesting. I can see your point, thank you. Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc