Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

When Dexter's on the Internet, can Hell be far behind?"


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

SubjectAuthor
o Re: RFC 4121 & acceptor subkey use in MIC token generationGreg Hudson

1
Re: RFC 4121 & acceptor subkey use in MIC token generation

<mailman.11.1698192602.2263420.kerberos@mit.edu>

  copy mid

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

  copy link   Newsgroups: comp.protocols.kerberos
Path: i2pn2.org!i2pn.org!newsfeed.endofthelinebbs.com!news.quux.org!tncsrv06.tnetconsulting.net!.POSTED.mailman.mit.edu!not-for-mail
From: ghud...@mit.edu (Greg Hudson)
Newsgroups: comp.protocols.kerberos
Subject: Re: RFC 4121 & acceptor subkey use in MIC token generation
Date: Tue, 24 Oct 2023 20:09:20 -0400
Organization: TNet Consulting
Lines: 31
Message-ID: <mailman.11.1698192602.2263420.kerberos@mit.edu>
References: <202310241950.39OJoa0Z000708@hedwig.cmf.nrl.navy.mil>
<3db2752e-565e-1f64-b354-9031a2fe9334@mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: tncsrv06.tnetconsulting.net; posting-host="mailman.mit.edu:18.7.21.50";
logging-data="25464"; mail-complaints-to="newsmaster@tnetconsulting.net"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.15.1
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>, <kerberos@mit.edu>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing;
t=1698192599; bh=AxsWuiZ1pZtxnzLD+Kz7ki0CYxdzBTIyT6qymdD37JE=;
h=Message-ID:Date:MIME-Version:Subject:From:Content-Type;
b=SyTBrcWzD5kruo9iWBGAjoL19lKeQJVmHUB4b7GMVmhwsFjGP8NV3MRLZW4IIQfLo
Uyxy0wqUGZJalzww7C8+gG2yO9t/0muFZy6Ix5Nlv0oKgr3U1tr5qyAVeHg3WgH3sH
7NU8Bxtz9DDbghgqXtEL356c9kMt6vmIfnuYTyM0PyQzSMe/Nyi25qgd4heAvMRINK
y4RvvfTfBXrXwBjRaYFBuajdjVIWEmfn1/0ZRF59NOXqvfSTKA2NP6gzjXYAZK7EHn
3M4ZKOncqlRuDoFxFcl6JxJYaDC6KrZ8HLfPzI48+wiJrESEzoSvqCRJzkNhqKDCTD
TNkxY9KotLCiQ==
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; pr=C
Content-Language: en-US
In-Reply-To: <202310241950.39OJoa0Z000708@hedwig.cmf.nrl.navy.mil>
X-EOPAttributedMessage: 0
X-EOPTenantAttributedMessage: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b:0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS1PEPF0001709C:EE_|SN4PR01MB7454:EE_
X-MS-Office365-Filtering-Correlation-Id: 28bed6b0-fa97-46ae-9a39-08dbd4eeac84
X-LD-Processed: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b,ExtAddr
X-MS-Exchange-AtpMessageProperties: SA
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: G9jK4393VbeZNSOGcOnEJAzZZWml6Z8GyOctNemEm47V2VPRrlv0rU/PqjJzFmTcAtUb5k/ZV9tIlZ4Z4kVSAZUlub3wkvKgBxEGwzGB1vYM8Llrm9RQx7jogR57B9Da7zQ/kZ/g/l4Xmfj6iTHJS0kt8yVeJpgO3BEi6BvgLk1hU3fqk2FKLYlK1tURhuvSgjBKpJnvld+n2ZNpEPnKA1F35nhgHXn3RBJ/4lqM8cQMUjCYFWArs8hiPFhhd3TsEVgJhsPHCu9Q5NSXBmbl26XYdZDAfQ3zLprmO1XxPFc/4p3LVot0sQ/Nak19QUMeoWP7/ffGgUYAXOwZxP+AQtKeTLnv+Z4JQdacLI02YqrL6ewXi5hosyO9pFuTjBBD11hoSLJKoZgLjLt7MKxxkPkmAL0+n71UOZlxK71B0QnhxN0QtsZyAHtYaKYkpZ7oHIVVgWHviMM324CxU94BcROoKgXu9R+v+Pj7FrrhCB+WzhzyZVUKqlrc0VXK3Eg0ibRTNYL8GjWc2GnCktoD0zDWpVWsnVcBUPqK8cHi7Vp5dUqwUn3iHRw+ASyQrhCfoUezZF+KVl+pPNanyfUVWYBQzZtqafQLLBlnFiYhpFMkMEcOcK1AZLfVycPdTsuOzji0UYD1xp61/wZprBu4/yRgBqf4glObgbZIu857nxBJTxIkCrqP7Oml+1RWgQhF408MJcJWmzrPcWu2+rldAQ14SYZHNlcjK+aeVwBXTCH7sh2YsyuMZb0Q5iITxj1AJC9/+J26rnifZ4rb19RrCQ==
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:(13230031)(4636009)(346002)(136003)(376002)(39860400002)(396003)(1800799009)(451199024)(64100799003)(31686004)(26005)(426003)(356005)(70586007)(83380400001)(86362001)(8676002)(5660300002)(786003)(75432002)(336012)(53546011)(7696005)(6666004)(6636002)(316002)(478600001)(2906002)(31696002)(68406010)(2616005)(36756003)(956004)(43740500002);
DIR:OUT; SFP:1102;
X-Auto-Response-Suppress: DR, OOF, AutoReply
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Oct 2023 00:09:36.1608 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 28bed6b0-fa97-46ae-9a39-08dbd4eeac84
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-AuthSource: DS1PEPF0001709C.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR01MB7454
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: <3db2752e-565e-1f64-b354-9031a2fe9334@mit.edu>
X-Mailman-Original-References: <202310241950.39OJoa0Z000708@hedwig.cmf.nrl.navy.mil>
 by: Greg Hudson - Wed, 25 Oct 2023 00:09 UTC

On 10/24/23 15:50, Ken Hornstein via Kerberos wrote:
[Disputing the following comment in k5sealv3.c:]
> 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.

> 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!

I believe mutual authentication is frequently omitted for HTTP
negotiate, but that's a minor point as in that case there's no acceptor
subkey.

Whether the initiator can generate per-message tokens before receiving
the subkey depends on whether the mechanism returned the prot_ready
state (RFC 2743 section 1.2.7) to the caller after generating the
initiator token. RFC 4121 does not mention prot_ready; I couldn't say
whether that's an implicit contraindication on setting the bit. I'm not
aware of any krb5 mechs setting the bit at that point in the initiator,
although I recall Nico talking about maybe wanting to do so.

The comment was written twenty years ago by a developer no longer
working for MIT, and I don't recall having any conversations about it
before this one.

1
server_pubkey.txt

rocksolid light 0.9.8
clearnet tor