Rocksolid Light

Welcome to RetroBBS

mail  files  register  newsreader  groups  login

Message-ID:  

Victory or defeat!


devel / comp.protocols.kerberos / RFC 4121 & acceptor subkey use in MIC token generation

SubjectAuthor
o RFC 4121 & acceptor subkey use in MIC token generationKen Hornstein

1
RFC 4121 & acceptor subkey use in MIC token generation

<mailman.10.1698177051.2263420.kerberos@mit.edu>

  copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=386&group=comp.protocols.kerberos#386

  copy link   Newsgroups: comp.protocols.kerberos
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!tncsrv06.tnetconsulting.net!.POSTED.mailman.mit.edu!not-for-mail
From: kenh@cmf.nrl.navy.mil (Ken Hornstein)
Newsgroups: comp.protocols.kerberos
Subject: RFC 4121 & acceptor subkey use in MIC token generation
Date: Tue, 24 Oct 2023 15:50:36 -0400
Organization: TNet Consulting
Lines: 61
Message-ID: <mailman.10.1698177051.2263420.kerberos@mit.edu>
References: <202310241950.39OJoa0Z000708@hedwig.cmf.nrl.navy.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Injection-Info: tncsrv06.tnetconsulting.net; posting-host="mailman.mit.edu:18.7.21.50";
logging-data="10076"; mail-complaints-to="newsmaster@tnetconsulting.net"
To: kerberos@mit.edu
Authentication-Results: mit.edu; dmarc=pass (p=reject dis=none)
header.from=cmf.nrl.navy.mil
Authentication-Results: mit.edu; arc=pass smtp.remote-ip=18.9.3.17
ARC-Seal: i=2; a=rsa-sha256; d=mit.edu; s=arc; t=1698177050; cv=pass;
b=EQUjS5EoSIBcTkrwjYenND0r0hfc5w0NAFPBdcGgyqFS7pA7Nol/et4bLfDSy/HktOofcHmG334lP6SB6bUPUaZOsX80r/jm3DEDYTa9S2G1wBkn6IvHkdCpcIIN/x40keaw8SLvn0nzJ6iH1zxlx8DfNOk1XIr15LJc78is038WXvXCIrLWYvka+GA2OFmhVwe96CMzrtKrjgKZNunIiFK1gZ2HryVttqMYPX12vD8W7gN2CxGc6gsFYO0b2KmTPcPG5qBM2h3p5KDJZFCYufJmH5HJO57HC+df45FXHXXa94htiRcUHfj0sYXnbAtInKGDhXz/jN2FtnEIjxfO6w==
ARC-Message-Signature: i=2; a=rsa-sha256; d=mit.edu; s=arc; t=1698177050;
c=relaxed/relaxed; bh=HXeqL6UDCVvG3zwy9JOzLXCiqfgWMqbi4dlGl9VDY4M=;
h=Message-ID:From:Subject:MIME-Version:Content-Type:Date;
b=PVwQdoggBHaLsxC/17oDNdoDZrySJ1vbX6qlqxfRmmuX/etF+QBFllK4QVMI9u57DsYnQNzHGgkkCxhF6xPZeMD8KJ3XZ44dHO2dKIR1xp7tYS0zth4n9WqnFiSMN1gEG5xpLKATfPaWGKg2VfJLawRhKXj9i+X66CNQI1JeJfbJIOEhkZgOryWCUVjN16VuPxSsmzvaYWSzSJmAxxCw6u+ObcTCXmoCYxrpFghjrlYJnUgmK27rTe6oYYsOqoSpBpF8ec9wuHYPIbUkdlNhBdD+kaJjOv9phEvY8Bj5hkWkgCg1iZ4KqUdknxufCoV1r2XhkekONqT9L6tp1f7fGg==
ARC-Authentication-Results: i=2; mit.edu; dkim=pass (1024-bit key;
unprotected) header.d=mitprod.onmicrosoft.com
header.i=@mitprod.onmicrosoft.com header.a=rsa-sha256
header.s=selector2-mitprod-onmicrosoft-com header.b=nDOwoI8H;
dkim=pass (2048-bit key;
unprotected) header.d=nrl.navy.mil header.i=@nrl.navy.mil header.a=rsa-sha256
header.s=s2.dkim header.b=ZHWfOKS0
Authentication-Results: mit.edu; dkim=pass (1024-bit key;
unprotected) header.d=mitprod.onmicrosoft.com
header.i=@mitprod.onmicrosoft.com header.a=rsa-sha256
header.s=selector2-mitprod-onmicrosoft-com header.b=nDOwoI8H;
dkim=pass (2048-bit key;
unprotected) header.d=nrl.navy.mil header.i=@nrl.navy.mil header.a=rsa-sha256
header.s=s2.dkim header.b=ZHWfOKS0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=bBIk1FQblfpE9usPtfAu5GB76lGZ4d3aGcRa+0NukVLuHggtzqIF6BVPSQn2pDyBfIf8jgaXaIvBrHxbAR0SdsPdP6HdHyrznvo6tywx3bvgWkYu0Dwfh63WimhYfFaj+rLOfS9l+yAZH42raqm1NOcoyRGZA6/wHmhUPW0ERt47YQAfxTcs6aCm660HySkaJmnXhQZsF5/ab0dkOExKcHQOdYWNxL5mq+4XIzxHWnvTkUmj2grkI8SiP+zDOvvs2qJVL0Z2ltet76TYA/kmb+K+RiwaQDSOWHCClYlpY14DsgHH+99XitdUsLq3GwNxrPV54FPBfNE0FiV55m8h1A==
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=HXeqL6UDCVvG3zwy9JOzLXCiqfgWMqbi4dlGl9VDY4M=;
b=Ji0kKMhVF5NvX19E2f+igX0KgGZy688chxQxuVhQYeboW3XrmNudy0QKu9b951hEXtmi8uWGTCSFmO2IXgcUXZ8ZSc0T/xyN4KVCihQMTCVDokfpFLzqNUVA+Ykg5OgFL7WCEZyjsXxUsVLF27uh3B74ieXTg04LULssy+naHVK7WrtquU10byeJ9HEIyruY86shDVOEtm+iAP2QjgNgj817W64rp5UkBi5iUXXa0dYxUNV9h7ZCHRLEuRSvAO2X88OG+P6aNq9ySTONu4FsuKuiCafu8KjP2nqp/Gp28i1ELOWL7PY5GJA2qqpmoVWPakDRnENh3bq80iwh3wTxlw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
140.32.61.234) smtp.rcpttodomain=mit.edu smtp.mailfrom=cmf.nrl.navy.mil;
dmarc=pass (p=reject sp=reject pct=100) action=none
header.from=cmf.nrl.navy.mil; dkim=pass (signature was verified)
header.d=nrl.navy.mil; arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=mitprod.onmicrosoft.com; s=selector2-mitprod-onmicrosoft-com;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=HXeqL6UDCVvG3zwy9JOzLXCiqfgWMqbi4dlGl9VDY4M=;
b=nDOwoI8HBEHT9H9iSju6VQHMCRc+EJezq6A3MUGaKWhjZZxoLgp4OsmRlJCdgDIMF1fUXKrYMfveaa+LY+I3yBmyT6MnvhL1JTclQjG0PWoR01zrqmw1KPO84w6dMB6+i8/ddTpRM9tDFWMnkZHl/GkTFkfVg6fNjXux85vdA14=
Authentication-Results: spf=pass (sender IP is 140.32.61.234)
smtp.mailfrom=cmf.nrl.navy.mil; dkim=pass (signature was verified)
header.d=nrl.navy.mil;dmarc=pass action=none header.from=cmf.nrl.navy.mil;
Received-SPF: Pass (protection.outlook.com: domain of cmf.nrl.navy.mil
designates 140.32.61.234 as permitted sender)
receiver=protection.outlook.com; client-ip=140.32.61.234; helo=mf.dren.mil;
pr=C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nrl.navy.mil;
h=message-id : from :
to : subject : mime-version : content-type : content-transfer-encoding :
date; s=s2.dkim; bh=HXeqL6UDCVvG3zwy9JOzLXCiqfgWMqbi4dlGl9VDY4M=;
b=ZHWfOKS0R6PkBEY8TNZqj9OyBxyJHeEzmRcZQYKGOzSInR7OExrbPvei1WyRlXLsfzIw
44N1nu2oUZaa4G9PGG46d2VvKYuL6XtRrS38VNi3HV1Ur4DIegd0L/ttFWR5xTXvkuW8
4JpAZowlGIcNMdCZmoC9lNc5kBDpwmXb3PYT2p7H8K724+XMmjzCYWcJDU9yl74kpumC
sJ/2h617nio2PG767W90C0QLXf+IYx7oCOsPZfe4fudR2ppS6tp7pMFNzn/RVLpLs4My
Tcy5JshxNaZMh83fF9zzWkH56tV23UoMcf/7AFcNT2zXLIKbNuz/sPwfferK4ZZoRIrJ Pw==
X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4
WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d
gD\SW #]iN_U0 KUmOR.P<|um5yP<ea#^"SJK;C*}fMI;Mv(aiO2z~9n.w?@\>kEpSD@*e`
X-NRLCMF-Spam-Score: () hits=0 User Authenticated
X-NRLCMF-Virus-Scanned:
X-EOPAttributedMessage: 0
X-EOPTenantAttributedMessage: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b:0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL6PEPF0001AB55:EE_|SJ0PR01MB6368:EE_
X-MS-Office365-Filtering-Correlation-Id: bcca07e8-ff10-4919-463b-08dbd4ca7f88
X-LD-Processed: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b,ExtAddr
X-MS-Exchange-AtpMessageProperties: SA
X-MS-Exchange-SenderADCheck: 0
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: ZQF1jCWcT+WkdJ+iZVCERVFZn63wwGO5BJGmwM13TELivAOiPvOalfOMchlzNFTj8XQn1im8pEigGlTS6qn7Dv+sHkzwt/Nu7BOGWSxaXVLM4y+ZSFYaVDGiFQDGYq35CqQqIh4L7CO0jgSgGyVOCa+cDG5UVBM9iDolaIatfsWpEobNhfNvkrLHWZV2stKKa64OLB3xNXd8qYeR7vE0CYBW5aUNGf99e2JFkqHWg1ClMlgMgpRYzFGcj/Wtx0hjYby8+BL6UDB//WUSwoLHDq/tymlHaqDuBenJEbFjisFstQ6VLmCXVmZN+WYX6mNLs6BQlQkXGHt3XGqZzuypLtGjDZyfxpemsYWFlUZZt7dJUtR7pzw4mSJTB9KoNXS/lgtgmLohsegk1MiLPduFnfbaU7MvdX9tU0PyMSzIF6/W9H52cGs3MMRFsqsBEu4LzDyNRMBLHeFgFAak/zMmikMPmg5vR8ZE/uKvtTaG26xbtaN3vUEkzFhVScO3zk+Ze2Cj6vwd1lwb5UinP1EzLaXZCiH9X8NIAfiKEZyO823p2Zk4gWp4UiOxFpLNXqPzOZJmJgLklCO86F7KQrfCSjD6fiO1189D50uVR+RC9HINEZZ0x0s1fOd/NwwtSjAkkkPJ1OuZ9+suHZ2bMta9sSpTFvmHxCWqZX7vVR1O6zj+NvljSZ30GpE+wcQ3n+LKYNkm2wiaJdhnLY5PZN4yGg==
X-Forefront-Antispam-Report: CIP:140.32.61.234; CTRY:US; LANG:en; SCL:1; SRV:;
IPV:NLI; SFV:NSPM; H:mf.dren.mil; PTR:mfw.dren.mil; CAT:NONE;
SFS:(13230031)(4636009)(396003)(136003)(376002)(346002)(39860400002)(61400799006)(48200799006)(64100799003)(451199024)(5660300002)(70586007)(68406010)(2906002)(786003)(316002)(34206002)(498600001)(8676002)(956004)(1076003)(26005)(336012)(426003)(7636003)(83380400001)(356005)(86362001);
DIR:OUT; SFP:1102;
X-Auto-Response-Suppress: DR, OOF, AutoReply
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Oct 2023 19:50:38.8832 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: bcca07e8-ff10-4919-463b-08dbd4ca7f88
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-AuthSource: BL6PEPF0001AB55.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR01MB6368
X-OriginatorOrg: mitprod.onmicrosoft.com
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: <202310241950.39OJoa0Z000708@hedwig.cmf.nrl.navy.mil>
 by: Ken Hornstein - Tue, 24 Oct 2023 19:50 UTC

To give some background, we are required to do security scanning of our
systems using Tenable's security scanner product (which is variously
known as Nessus, Tenable.sc, or ACAS if you're in the DoD; I'm aware
that these all aren't the same thing but in practice they all seemed to
be lumped together). This requires the scanning software to actually
log into our systems and run a bunch of commands.

This product actually supports Kerberos (ssh using gssapi-with-mic)
and I got that working fine to our Linux systems. Those systems are
running the CentOS vendor ssh which is linked against the CentOS MIT
Kerberos libraries. It is worth noting that the client side Kerberos
implementation on the Tenable side is written in the NASL language and
is relatively primitive; the source code to this implementation is
available and it is relatively straightforward to follow.

I tried to get this working to MacOS X systems, using the vendor ssh
which is linked against the Apple Heimdal-based Kerberos libraries, and
that did not work (but did not return or log a useful error); using the
CentOS vendor ssh client worked fine against the same system. After a
whole lot of debugging (which included staring at a bunch of hex dumps
and hand-decoding some ASN.1) here's what I found.

The Tenable code is doing the AP-REQ/AP-REP exchange with the MacOS ssh
server fine, but the GSSAPI MIC is being rejected by the sshd daemon.
This is because (a) the AP-REP from the ssh server includes a subkey
(b) the MIC sent by the Tenable client does NOT use the subkey from the
AP-REP but instead unconditionally uses the service ticket session key
and the 'flags' field in the MIC is 0x00 (c) the Heimdal code rejects
the MIC based on the rules in RFC 4121 ยง 2.

This works against MIT-linked ssh daemons because even though the MIT
code does return a subkey in the AP-REP it does not enforce the requirement
in RFC 4121. Instead the appropriate code has this comment (k5sealv3.c):

/* Two things to note here.

First, we can't really enforce the use of the acceptor's subkey,
if we're the acceptor; the initiator may have sent messages
before getting the subkey. We could probably enforce it if
we're the initiator.

(There's more, but not exactly relevant to this). The code below
this comment only uses an acceptor subkey _if_ there is one available
and the initiator sets the appropriate flag in the MIC token.

So, obviously this is a problem with the Tenable client code and I
have to figure out how to submit a bug to them (which sadly might be
a challenge, sigh; at least from my looking at the Tenable code it's
80% of the way there). But this makes me wonder ... is the above comment
correct?

I ask because it doesn't seem to me like it is. I was under the impression
that when you're doing mutual authentication (which in my experience
is pretty much all of the time) you can't send any other GSSAPI tokens
until authentication is complete and if authentication is complete then
you can definiteley be assured any subkeys have already been exchanged.
Clearly Heimdal enforces this and other than this obviously wrong client
code I am not aware of any operational issues. Am I wrong? I admit
that is always a possibility!

--Ken

1
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor