Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  nodelist  faq  login

Intel CPUs are not defective, they just act that way. -- Henry Spencer


computers / comp.protocols.kerberos / Re: Always prompting for OTP

SubjectAuthor
o Re: Always prompting for OTPGreg Hudson

1
Subject: Re: Always prompting for OTP
From: Greg Hudson
Newsgroups: comp.protocols.kerberos
Organization: TNet Consulting
Date: Tue, 10 May 2022 19:46 UTC
References: 1 2 3 4 5 6 7
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!tncsrv06.tnetconsulting.net!.POSTED.mailman.mit.edu!not-for-mail
From: ghud...@mit.edu (Greg Hudson)
Newsgroups: comp.protocols.kerberos
Subject: Re: Always prompting for OTP
Date: Tue, 10 May 2022 15:46:26 -0400
Organization: TNet Consulting
Lines: 45
Message-ID: <mailman.62.1652212017.8148.kerberos@mit.edu>
References: <CAJhaRZLGArFp=hu0X97yQOKy=W=YCk4eaQXip1+28Vp2oWta+w@mail.gmail.com>
<cfb89a7a-ab03-f705-ffcf-5ad01e4700dd@mit.edu>
<CAJhaRZKzi91odO9Eu87J7z6xC_EepWrxSAL++EB9Yh6HCZPufQ@mail.gmail.com>
<8735hhs1om.fsf@hope.eyrie.org>
<CAJhaRZ+i0O37fdzNzhg8PXzPtjeEgdmwv_hAT4m2hFv9VVqeoQ@mail.gmail.com>
<87pmklql3g.fsf@hope.eyrie.org>
<250ae6d9-8607-2c6e-1f6b-418bf6ef410a@mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Info: tncsrv06.tnetconsulting.net; posting-host="mailman.mit.edu:18.7.21.50";
logging-data="25334"; mail-complaints-to="newsmaster@tnetconsulting.net"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Cc: kerberos@mit.edu
To: Russ Allbery <eagle@eyrie.org>, BuzzSaw Code <buzzsaw.code@gmail.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing;
t=1652212015; bh=s2oxuEt47xfzYtPGw6d5PBAe2uRglbJSMwPvzmVx5eA=;
h=Date:Subject:To:Cc:References:From:In-Reply-To;
b=AKoVw6RjtPzMNGEt61WuSDQxpj6QY6n1u5VUECyuhRfzSKwI0Ne+2norZze0tIuql
AaIi6JEsocVZ5PQdgz6PX4PPDR0gRPVoQlWkXCpXcQRo8fLSEMAGqWa+SjN0uP2Px3
K38qt9Xa8HFbUno/xJvJRCTiWYKJl4tOibTqYhSyC3tkluY+zMsG4As1GDekE68H5e
gncAZ0+jzghT3yMPKSjyVp4aJlOoxmZ86sFFEzqY0jSyhTKqfJUYRXseOttJSsDVJB
fQUqVy1U2cEIDCyR1Z5mpZbUa+BjQMN0qj45xcnWEa5PY1UQGyeTS/hM2booe9e8mC
Vny++reRE9DCw==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=F1jM65qzXM67mVWGnDg/4IHFftfDkmpc3BXY//hBsivwr80nNWXnAUn3R5KN198CudEaFJdTzTSfN5pT/gq3EwloeJgculYWtQ8zxYmCr1vldm2R0EueJYgpNWijqnTpJxi5hTwdwFAvjCSrDfAN62+kQO0CEHnq1qfp7US1A6ta59RQe6WKR2y2QzxMBE+HSaPBFgt04UV0sieDxIjfrXuOtekVcWdGLaCCQ2imbJJVs3Vb2jE6Z/YB8a2ApDOnhHZDNGLJe0qY1F1F9Y8zlths0jaLsJWNrcdu2S1ZCTjGsPUWH71Yvbq8vuAggbX4Jp/y7cM7LP9jhX6Ym2UhAg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector9901;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=s2oxuEt47xfzYtPGw6d5PBAe2uRglbJSMwPvzmVx5eA=;
b=QjLxVdKyk7qA2TKpxRRPDyGtA1YEPdf0sx4cvJLiOHg1KA4C3R1I23z742pyzsgwiuredBCZJYzRbZ4ZJaFBNYWkDEzavVZ+09fSAOLgTxSecBPG3MKzMlwMTs1cOIsB+W6llYK1QHf1uVC/GQPdFxhiybj0KpwjzYs0bEvpBaMbB9/EkS2phVgF5Ypj085sCx0wQKUMLVg/2QwStVly3/T3znleisNCBEIbaoGf5T07m0JWUtscahCO0SS6MObLA7Kuo49BOVQi9Jv7YfZpMvmQb2JvTazDIJ9Y6+UjEpO/j7ggPjxgqf+9fSoOBpxpNk/LS5svvo7INWdVM/1W8A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
18.9.28.11) smtp.rcpttodomain=mit.edu smtp.mailfrom=mit.edu; dmarc=pass
(p=none sp=none pct=100) action=none header.from=mit.edu; dkim=pass
(signature was verified) header.d=mit.edu; arc=none (0)
Authentication-Results: spf=pass (sender IP is 18.9.28.11)
smtp.mailfrom=mit.edu; dkim=pass (signature was verified)
header.d=mit.edu;dmarc=pass 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;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing;
t=1652211988; bh=s2oxuEt47xfzYtPGw6d5PBAe2uRglbJSMwPvzmVx5eA=;
h=Date:Subject:To:Cc:References:From:In-Reply-To;
b=DXmADNeneGNnzrS0g2osUfuUVGtr+kZD2rBI3zn18YhtBXGbxQj5wb28QWUG3g0cb
SV2KPuGAdlHm6HWwvg6fgjSX7BCiBz6gf5b5Nxs6L4JyDgAYThnE+04k/FANdfnM0s
3hcxlaGZsFiF23ZKvYJqG5BhFENp+63sHFLs89UrwjYyPHTJwIORHe7I7YPTcFRREU
ZL9eqV3abve4SPRxgynrRYS5+2/pr2U6LQJvHE/3ZLNgKYb43ICPX2V+Ofzfh0AGuu
j2Tcq3XezloyEcyzxjRuAbReaIhlnmCZ7D4jMFohf2MELCJw4czwa1sMmJf9b2U46H
YA3vc8PcXjpBQ==
Content-Language: en-US
In-Reply-To: <87pmklql3g.fsf@hope.eyrie.org>
X-EOPAttributedMessage: 0
X-EOPTenantAttributedMessage: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b:0
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 8b43560b-4b3b-4ac6-3b95-08da32bdc845
X-MS-TrafficTypeDiagnostic: DM6PR01MB5370:EE_
X-LD-Processed: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b,ExtAddr
X-MS-Exchange-AtpMessageProperties: SA
X-Microsoft-Antispam-PRVS: <DM6PR01MB53701C970C6AA33981160B2BBCC99@DM6PR01MB5370.prod.exchangelabs.com>
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: nHb7j9Imh5HpazHmcrgkAZwYV+SMno1aahyaZSOHNr987NWoXCTvVj5B6NkI0aeLfceYI3Ghbf+ypzjX9RZUQGJoxdSOVAC3O/dRI07ooXCNCIga7WoFQlcHnnhzdDyf0jzRXcIZYcd4FZaLAYbBhvU9K4GCYts3oxPjyEX8SiWbKhguJUm3+WXWfYQJFash7gXRVl3+ELuZaUP6Yx2R2hz1LzhA6KC9Y7Ep41X8mglrbETXTtg8BgsV77gwmCvzEmuOnUBzFf3wcI+r71Cev0uZ5On/pMGP2dt3eGk3kLL19OcbNQoXlVKXfUKIqCUEUGxIbOXBRVQT+4RiveJWOnj5DTOa99GugoOIts85tMzFsHMjA9+snLD3TxNkDuB2lV1yS6eQ6pbsL6+WYq6CTX0onxC7eVDsXm6oNWlNIasa9/jnmXLAr6PGRXmUf5VwE4DHozhIwZcK2EaUO72Inowmr3gc99IX5BU2rmGnrpp0KxVHKyLf20V/ouQYFFQP+te6EuVADswWIDWEKtaZ4UkMtKRnvyOnPSOY2+2FDbRCwCpiSP8Vq9SWUPqQiXFRQH+PBph1thsjw1xPce7sLct2YX0Meu279zlgQ08DcgMDWtZXz21ZyWlOJuPchjVz2AHR7tltoLEHi1ICiInZW4wwQbMbyi1h25oX+w05fZ3nSVvuXrUeJo+coDIQD3w4aX+JEol83CbDsoyWTxuMOQ==
X-Forefront-Antispam-Report: CIP:18.9.28.11; CTRY:US; LANG:en; SCL:1; SRV:;
IPV:CAL; SFV:NSPM; H:outgoing.mit.edu; PTR:outgoing-auth-1.mit.edu; CAT:NONE;
SFS:(13230001)(4636009)(31696002)(53546011)(86362001)(508600001)(426003)(336012)(83380400001)(3480700007)(75432002)(26005)(2616005)(956004)(356005)(36756003)(5660300002)(6706004)(110136005)(786003)(316002)(2906002)(68406010)(70586007)(31686004)(4326008)(8676002)(7696005)(43740500002);
DIR:OUT; SFP:1102;
X-Auto-Response-Suppress: DR, OOF, AutoReply
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 May 2022 19:46:31.3253 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 8b43560b-4b3b-4ac6-3b95-08da32bdc845
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-AuthSource: CO1NAM11FT003.eop-nam11.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR01MB5370
X-OriginatorOrg: mit.edu
X-BeenThere: kerberos@mit.edu
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: The Kerberos Authentication System Mailing List <kerberos.mit.edu>
List-Unsubscribe: <https://mailman.mit.edu/mailman/options/kerberos>,
<mailto:kerberos-request@mit.edu?subject=unsubscribe>
List-Archive: <http://mailman.mit.edu/pipermail/kerberos/>
List-Post: <mailto:kerberos@mit.edu>
List-Help: <mailto:kerberos-request@mit.edu?subject=help>
List-Subscribe: <https://mailman.mit.edu/mailman/listinfo/kerberos>,
<mailto:kerberos-request@mit.edu?subject=subscribe>
X-Mailman-Original-Message-ID: <250ae6d9-8607-2c6e-1f6b-418bf6ef410a@mit.edu>
X-Mailman-Original-References: <CAJhaRZLGArFp=hu0X97yQOKy=W=YCk4eaQXip1+28Vp2oWta+w@mail.gmail.com>
<cfb89a7a-ab03-f705-ffcf-5ad01e4700dd@mit.edu>
<CAJhaRZKzi91odO9Eu87J7z6xC_EepWrxSAL++EB9Yh6HCZPufQ@mail.gmail.com>
<8735hhs1om.fsf@hope.eyrie.org>
<CAJhaRZ+i0O37fdzNzhg8PXzPtjeEgdmwv_hAT4m2hFv9VVqeoQ@mail.gmail.com>
<87pmklql3g.fsf@hope.eyrie.org>
View all headers
On 5/10/22 14:49, Russ Allbery wrote:
We want the full OTP+password string just passed without modification.

Ah, okay, so then in theory the problem could be solved entirely within
the Kerberos libraries, although I haven't wrapped my mind around the
problem Greg identified.

I will try to explain again.

The Kerberos protocol was designed to be somewhat resistant to phishing.
 If I set up a rogue KDC and somehow convince clients to authenticate,
the clients do not simply send me their passwords.  This resistance
isn't perfect; by asking for encrypted timestamp I can probably get the
client to send a ciphertext that I can use to conduct an offline attack,
and I can probably influence the client to use a fast string-to-key
function by pretending to only support an older encryption type.  But
it's still a goal.

FAST OTP does not have any phishing resistance, at least in the mode
that is used in practice.  Whatever the user types in as the OTP value
is simply sent to the KDC to be inspected raw.  On the positive side,
FAST OTP can only work over FAST, and one can presume that the FAST
armor key was obtained in a way that authenticates the KDC to the
client.  So it's not as easy to receive client authentications as a
rogue KDC as it would be in the original protocol.  But depending on the
scenario it might still be possible.  pam_krb5 has some idea of the
authentication scenario (it's a system login of some kind), but libkrb5
does not.

If an OTP client preauth module used the password as the OTP value, that
would make it easier for a KDC to completely subvert the phishing
resistance of the original Kerberos protocol.  Again, prompting
separately isn't a perfect solution as users confronted with an "Enter
OTP Token Value" prompt are as likely as not to simply re-enter the
password.  But it would still be worrisome.

I'm assuming this is because the Kerberos library doesn't think that the
passed-in password can be sent after the FAST negotiation and therefore
re-prompts internally?  I'm not sure I entirely understand the logic flow
here.

The FAST negotiation is irrelevant, except insofar as it makes the
design of FAST OTP possible.  Client preauth modules implementing OTP
mechanisms simply don't consider the Kerberos password to be the same as
an OTP value, so they ask for the OTP value via the responder or prompter.


1
rocksolid light 0.7.2
clearneti2ptor