Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Progress means replacing a theory that is wrong with one more subtly wrong.


devel / comp.protocols.kerberos / Re: Using PKINIT with ECC

SubjectAuthor
o Re: Using PKINIT with ECCGreg Hudson

1
Re: Using PKINIT with ECC

<mailman.61.1700425370.2263420.kerberos@mit.edu>

 copy mid

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

 copy link   Newsgroups: comp.protocols.kerberos
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!tncsrv06.tnetconsulting.net!.POSTED.mailman.mit.edu!not-for-mail
From: ghud...@mit.edu (Greg Hudson)
Newsgroups: comp.protocols.kerberos
Subject: Re: Using PKINIT with ECC
Date: Sun, 19 Nov 2023 15:22:29 -0500
Organization: TNet Consulting
Lines: 31
Message-ID: <mailman.61.1700425370.2263420.kerberos@mit.edu>
References: <8984fe41-f9a0-434b-a09c-df2bc88125dc@sec4mail.de>
<ae76ed5c-1399-401e-988c-ed2dbdfff6e7@mit.edu>
<202311191700.3AJH0hJD016758@hedwig.cmf.nrl.navy.mil>
<51e3d01f-4c52-490b-a0c0-f1ebbbe436e3@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="12219"; mail-complaints-to="newsmaster@tnetconsulting.net"
User-Agent: Mozilla Thunderbird
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>, <kerberos@mit.edu>
DKIM-Filter: OpenDKIM Filter v2.11.0 unknown-host (unknown-jobid)
Authentication-Results: mailman.mit.edu; dkim=pass (2048-bit key,
unprotected) header.d=mit.edu header.i=@mit.edu header.a=rsa-sha256
header.s=outgoing header.b=HNn9QkDI
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing;
t=1700425368; bh=+/RK/t93WlTAQwopIH8YpzNycmFpTqXBIcTZhRv9qlI=;
h=Message-ID:Date:MIME-Version:Subject:From:Content-Type;
b=HNn9QkDI99zlObk9ZeRuoCdn2gXVSRM2xkJOvamof0pD3VXC5f0XKJNGSvtI5r7Y8
7ivwV6F8PrG3Vkb9uzfUwh5+2YQkEH9EULdyLdf+cBpjj/Vrkur/mgNKnDZnNv/wfz
NBwYEwp8OfL1LaXF7dFY1TR1wjAg4vdl04EIqtjOO5Lsvj5RKNy9R6529Tz5ixSJqi
jN181Hi5KMUWUP+pMyXex651LKEgg1saGQzgMQH+pbS6DV9QeMIYIqauJ/dan41eOD
LvzTJtX/xj+OV4xeIPjA2OsZWRJgSTRY3DW1yCR+pskgSlE48CDVv0Ok9daQZTr+Cv
koBDdFj+WfkGw==
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: <202311191700.3AJH0hJD016758@hedwig.cmf.nrl.navy.mil>
X-EOPAttributedMessage: 0
X-EOPTenantAttributedMessage: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b:0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9D7:EE_|BL1PR01MB7699:EE_
X-MS-Office365-Filtering-Correlation-Id: 91c6a4a5-9806-4037-1a77-08dbe93d4a79
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: Rk0w35ZFYH+iM/UFB997wiOHLwaaq6lNKPr+jfx/t5DgYx72t/FqqglGkulgcJrWsqWra+/01T1PtVoZjMHS1uUvTxVQC5VODU4/b2r8a1PRpxAtNZIkdvDIJf7gYD8+0v25CKmz8xhwzsTxPV0xmr41v4CEQGff5Rq1gfDrAo5F6yJLR0t8ahXvRFf5aBlZMGilp6PqFGpPx4Xz0JMDqoKA690Ca5xULKSorP476MjDkD+853VjMl76T8vSo7MnstQmIgfbnobX1m96wa0xx8NpkcTbcKNG6AN6QulYG2vKpEl9k339ADmLMrjlC8G13CcbZ5TnBOMFLU810pNQDSBZoHJXrMrP3p9t5Fc5zyz+E5jTbwAgLz2XtpBW/pHXlxlEQO9N9hw5R5jfEt4SJ4iWXKr/avv7CCIwBOfAFHE/Lrqb7hn1/827Qb7I1KgM8Yt2WOW2qof33o/FAlzODA3jWGvfQqZYU9W+Y6DMePFhrVBxLlLVufbGY+OwQi6I8HW4dV6IB1YCv3H5LqfRjUWeVeTRgOmPd826JSZe21ASsam0DmV4BSzuMQnBrJm+XiX6ehUMEy5Alifr5us/kArp0RmsFCTJjkOjUgAruU892Q5Up1bEhW7F+BwCNJyKdgyXbmJ5k0tzlpyVCoj3kS3+npb60W0Q9imy8b/0ltQVVoRq0FxOiEZ07H1YwUckReQ5PxmsN4qGdTAd2OqPgJes9itLlb2SzPllyHHudtFYZu3FZfRr9qYA/+LfxQecZ8QJRs57kLWuSdOovywJlg==
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)(396003)(136003)(376002)(346002)(39860400002)(1800799012)(451199024)(64100799003)(2906002)(478600001)(53546011)(7696005)(956004)(2616005)(6666004)(86362001)(5660300002)(31696002)(6636002)(316002)(786003)(75432002)(68406010)(8676002)(70586007)(356005)(83380400001)(3480700007)(26005)(336012)(426003)(36756003)(31686004)(43740500002);
DIR:OUT; SFP:1102;
X-Auto-Response-Suppress: DR, OOF, AutoReply
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Nov 2023 20:22:45.2128 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 91c6a4a5-9806-4037-1a77-08dbe93d4a79
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000E9D7.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR01MB7699
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: <51e3d01f-4c52-490b-a0c0-f1ebbbe436e3@mit.edu>
X-Mailman-Original-References: <8984fe41-f9a0-434b-a09c-df2bc88125dc@sec4mail.de>
<ae76ed5c-1399-401e-988c-ed2dbdfff6e7@mit.edu>
<202311191700.3AJH0hJD016758@hedwig.cmf.nrl.navy.mil>
 by: Greg Hudson - Sun, 19 Nov 2023 20:22 UTC

On 11/19/23 12:00, Ken Hornstein via Kerberos wrote:
> I have mentioned this before, but ... is there any interest in adding
> additional trace points for every place where the old "pkiDebug" calls
> are made? Hidden errors when doing PKINIT are the bane of my existence
> and I feel that I'm not the only one. I understand there are concerns
> about making the trace log too verbose but I think every error could
> generate a trace message and it wouldn't add too much to the trace output
> when everything was working.

I would be happy to have more trace logging to diagnose PKINIT errors,
but converting every pkiDebug() call probably wouldn't meet the criteria
for good trace logging. We've already made a few passes in this area,
most recently one from you which went into release 1.20 (commit
34625d594c339a077899fa01fc4b5c331a1647d0).

Based on this thread, it is clear that there is still room for
improvement in the handling of PKCS11 errors. While we mostly handle
OpenSSL errors through the oerr() wrapper which trace logs the OpenSSL
error queue and sets an extended error message, we don't have any such
wrapper for PKCS11 errors. In this case, we now know that C_SignInit()
failed; here is the handling for that error:

if ((r = id_cryptoctx->p11->C_SignInit(id_cryptoctx->session, &mech,
obj)) != CKR_OK) {
pkiDebug("C_SignInit: %s\n", pkcs11err(r));
return KRB5KDC_ERR_PREAUTH_FAILED;
}

So only the generic "Preauthentication failed" message shows up in the
trace log (at the libkrb5 level) while the old debugging would have
indicated the failed operation and the PKCS11 error string.

1
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor