Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Optimization hinders evolution.

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

SubjectAuthor
o Re: Using PKINIT with ECCGoetz Golla

1
Re: Using PKINIT with ECC

<mailman.57.1700413646.2263420.kerberos@mit.edu>

  copy mid

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

  copy link   Newsgroups: comp.protocols.kerberos
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!tncsrv06.tnetconsulting.net!.POSTED.mailman.mit.edu!not-for-mail
From: mit...@sec4mail.de (Goetz Golla)
Newsgroups: comp.protocols.kerberos
Subject: Re: Using PKINIT with ECC
Date: Sun, 19 Nov 2023 18:07:16 +0100
Organization: TNet Consulting
Lines: 73
Message-ID: <mailman.57.1700413646.2263420.kerberos@mit.edu>
References: <8984fe41-f9a0-434b-a09c-df2bc88125dc@sec4mail.de>
<ae76ed5c-1399-401e-988c-ed2dbdfff6e7@mit.edu>
<81bc4460-b88a-4dfe-b538-e22805a086ea@sec4mail.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: tncsrv06.tnetconsulting.net; posting-host="mailman.mit.edu:18.7.21.50";
logging-data="11812"; mail-complaints-to="newsmaster@tnetconsulting.net"
User-Agent: Mozilla Thunderbird
To: Greg Hudson <ghudson@mit.edu>, kerberos@mit.edu
DKIM-Filter: OpenDKIM Filter v2.11.0 unknown-host (unknown-jobid)
Authentication-Results: mailman.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=IyneuUV8;
dkim=pass (2048-bit key,
unprotected) header.d=sec4mail.de header.i=@sec4mail.de header.a=rsa-sha256
header.s=default header.b=O2HBcjvQ
Authentication-Results: mit.edu;
dmarc=none (p=none dis=none) header.from=sec4mail.de
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=1700413645; cv=pass;
b=m7bBk+HrQZxET2X2UdqpxNioqtezNFG5np/5Y9ZoyhhnLDLcCDRjvw7LX19jx9VjwH4QoKZomEsAmZf5FcybpPY+jHLewo8aAu7NzvccWVD9oW+ZMAP8IJiCaPL5bnkV6IZ58Z6vtE7npB9QMEjW4QoohSx59MRZhSHFqDWRxG851aFzL2Q8phKU3kCx0xhsKT/8VsrBRTykx+QeGaj84S1hwaozdjFctoY9ekfF9ME3uMMKXbVjyntSYAhxqi0sESp3pDNI8u8VriFFT39yHxxL3iNXg/mPsZmfyZ3L9K+5B7FnB5pelimeWlLSzXDHlT6xgHsyyXerYgcbXGs+HQ==
ARC-Message-Signature: i=2; a=rsa-sha256; d=mit.edu; s=arc; t=1700413645;
c=relaxed/relaxed; bh=c5iK13sd7PTfLUTOUdRtn3VJFyZn+x+Z5K21Y0GD+zU=;
h=Message-ID:Date:MIME-Version:Subject:From:Content-Type;
b=E/5wZ2u/ZpA0Gwm6sCtbF+efONveEE1R6kEXn2RFkovZCk9fDkAcz8sjikyq5gy2biKvSNUwE+jZYRYjL8pKkPoMyjFnCSCqdKvjIqVxqrZNDxkCQjFShl9aPRhb8n6BUJRSnLnUuhsEL6KyVMK777LlOgGYYNlhzm4sNZCh4CU18JHUOt/rNTyJieuW5GwkuSzpvDYFupx9A695hANc/DLq+Az+urrVMj18iIoUsA0GHCdvtGzCckGOXJQBBffoLpiXoc1IP77oqz+ghndyrhx7yfVa3hWzweQBsclxc+agPG6IxkHPrQUJfwlOJ+BGIMdLfF8DZbpXg1hWpr1XRQ==
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=IyneuUV8;
dkim=pass (2048-bit key;
unprotected) header.d=sec4mail.de header.i=@sec4mail.de header.a=rsa-sha256
header.s=default header.b=O2HBcjvQ
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=IyneuUV8;
dkim=pass (2048-bit key;
unprotected) header.d=sec4mail.de header.i=@sec4mail.de header.a=rsa-sha256
header.s=default header.b=O2HBcjvQ
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=f1BvV1DYVkjL5p0JOnI3YdDd4EDyMkmarJiOnhJL8/n5Z7wyu3lqjWyhdfl6F7JbW/ivxTjIFaXnFKMtvtTdahBeUzwNPmioOL8s3Cp4vEnLBOITphLlLym7lzkNoM4fuYROUJ76bgDLNUsTDTcf1Ydv6C24tAAjYTO1XHN2iK8kTo+TqhRH0DdyOLncUeEFLWGQDev2SXDGOSueB67LWT8U9kOKc+UbTg/AvX6d4I1k3v9D2gPQp/O3vsffdpqWUfuYaugVRDERyda37ObblfthEL54WFBF3kPdnuFs+FDN971ISEsD0yO7uZdRBA5X4kU1aIvf34szXtr8MmGKMw==
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=c5iK13sd7PTfLUTOUdRtn3VJFyZn+x+Z5K21Y0GD+zU=;
b=SsaUxjmptx5rlGrDU7ATUIpRmx4zyiydCZ28//lzYHNWLubiVnkTsatUstFIUsgGpjcXGYIK63jCYkP+PvE6EEoQD2j+CzyRPBPqrKBSHZNekrGirfTAMulGR8EHeSEBLPQh+QpAyEyNUR4lg6oya/7EJJuJdiEOOaIQb3BssLAg+3ej9KrtNJQnvKRL10P8keHHzeZK/jITdubojNCuSP+178l9LqOtcJFW+s8AogwtVorw+gu2+ZOeaMwCRfT/E2Jmpxr7c1zE/8SG6SRqNxweLLSiSNIbZpJpOKNxxLI0jpm7xgqyWfA60RBLWLP9/ydG9S3KVJgq2g1ludJVdA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
31.220.85.254) smtp.rcpttodomain=mit.edu smtp.mailfrom=sec4mail.de;
dmarc=bestguesspass action=none header.from=sec4mail.de; dkim=pass (signature
was verified) header.d=sec4mail.de; 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=c5iK13sd7PTfLUTOUdRtn3VJFyZn+x+Z5K21Y0GD+zU=;
b=IyneuUV8l7fGtf4JmlHkiYlOIJ3ReOB7zeCy3utx27f6Rt3ChhGPNc3EeSCa3dGX+30bLC8Ipe8zE0AwDzcQoGs2Dsem2Kd8h44mvC9reULmNBY3REOrstNdKwDcYcJd+Ivfl8cKv3HkVqR27UCd0V4OzIQWrj6l26TkRvphYsk=
Authentication-Results: spf=pass (sender IP is 31.220.85.254)
smtp.mailfrom=sec4mail.de; dkim=pass (signature was verified)
header.d=sec4mail.de; dmarc=bestguesspass action=none header.from=sec4mail.de;
Received-SPF: Pass (protection.outlook.com: domain of sec4mail.de designates
31.220.85.254 as permitted sender) receiver=protection.outlook.com;
client-ip=31.220.85.254; helo=vmd109154.contaboserver.net; pr=C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sec4mail.de;
s=default; t=1700413637;
bh=mK0vfLVw3sUYGph4JxH3LQQqbkA49JJB07IxUU1o9mA=;
h=Date:Subject:To:References:From:In-Reply-To:From;
b=O2HBcjvQlmn6oJBhqPhjQUrlZrcs3/OGwCEYnGmy6JkNibcJGkQ9DXK/0uRNt0evZ
XWETH2mHeLU3HNzjESdeidQfEVPS11DsHsFGZxwuE3B5OD2jgq7LnplhR+g7jclcg1
YriKlIjMCoLX4vF6kgDkdh+Eal6FWgMUpoO3LeuY6nmpBL+drIiq8IP88EZF3Ao+EK
llezBe7YGQXHwLDOpAMCO34ZBQecZMhObY8AMQcf4FedOuOA0QNQd1AmiQFAAvchlD
xdLF/LKkynzIDe3T3+qkJ20P27UYUZG8gmOK+TDGVqCR1JkUqDL94sqQpleSs2nbbU
mtMj66/iXl7iw==
Content-Language: en-US
In-Reply-To: <ae76ed5c-1399-401e-988c-ed2dbdfff6e7@mit.edu>
X-EOPAttributedMessage: 0
X-EOPTenantAttributedMessage: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b:0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0001A106:EE_|CO1PR01MB6581:EE_
X-MS-Office365-Filtering-Correlation-Id: abc98c75-423e-4f87-643d-08dbe921fdb8
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: dCyc60jp/epD2tGczqQUzidB+qdilVeHHFqrVOnxBRYAmKyXRCT9CYN+YB/QQI1/ay+KAjJxPuwvgIaaFnszbuKz0+Gr2GBzGiOZUen3x7/pCsY6NMaHc1LKGK8JeLOf55QfK//up/S0SQ6Zy6EKMr29xa0TA6vgvm2aQLTnCiH33KxJfmrWzYTsJAvQsfQzGJOhvxGDIvM8FR0G1Isat75SDgLEh4xbamncDhbrYs+eYl15ID5wMdB5XL4PUbyt0MLcsXCZw+xr6MOc/O5MHsvfb2YA0JkHmU85zybf3FL1wsiC+hmIYdscvlycX3gsnVL4/BqVWl1xXlpuugxEACKdD5CPRE1i/dZe/r3/Dkfy2uKuF7M726qXcaNvxOBVknkz3df5VjPII4/Uf/oXWRU5ckFYGpFVsUrc/MAVHfSlaj+eg1ekmhrPCuRD7+6jywMIX9Fw0q9B14YjGQHXA+broKp6Os53cDPGkk1uA9+7sfWhDVw6LsY2VkE+nrYYgyVXZCpQS3b+eO2abpHRiNfneYeT5pH4WMfQsNNfHhvEElU+FRWw9DJKNAWqva8Ey6FY/m7k8L1RLiXkmimltqFwTCUXq/P7aXYWi8/hdX2vMnHbHCcno5b212Qv2uoIAmn1ZcYSlh7nDKlZihLDOAvpw+dDSV80hp6zqDCvZGjJ+pC86E4zKNY5KyeWuv1Pis7315g5hjEuopu81C1TRg==
X-Forefront-Antispam-Report: CIP:31.220.85.254; CTRY:DE; LANG:en; SCL:1; SRV:;
IPV:NLI; SFV:NSPM; H:vmd109154.contaboserver.net;
PTR:vmd109154.contaboserver.net; CAT:NONE;
SFS:(13230031)(4636009)(39860400002)(136003)(346002)(396003)(376002)(451199024)(61400799012)(64100799003)(48200799006)(5660300002)(2906002)(7596003)(7636003)(356005)(86362001)(31696002)(36756003)(53546011)(336012)(6266002)(83380400001)(26005)(956004)(2616005)(3480700007)(498600001)(6966003)(8676002)(70586007)(68406010)(316002)(786003)(31686004)(43740500002);
DIR:OUT; SFP:1102;
X-Auto-Response-Suppress: DR, OOF, AutoReply
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Nov 2023 17:07:20.0782 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: abc98c75-423e-4f87-643d-08dbe921fdb8
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-AuthSource: BL02EPF0001A106.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR01MB6581
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: <81bc4460-b88a-4dfe-b538-e22805a086ea@sec4mail.de>
X-Mailman-Original-References: <8984fe41-f9a0-434b-a09c-df2bc88125dc@sec4mail.de>
<ae76ed5c-1399-401e-988c-ed2dbdfff6e7@mit.edu>
 by: Goetz Golla - Sun, 19 Nov 2023 17:07 UTC

I have made some progress locating the problem which I would like to
share here.

When I am using openssl with the extensions file exactly as recommended
to create the client certificate and refer to the file in
/etc/krb5.conf, kinit works flawlessly with Public Key Algorithm
id-ecPublicKey / secp384r1. I can even use ECC for the CA certificate
without problems.

The problem is that we are using Yubikeys with the PIV function as
smartcards. Yubikey supports ECC with secp384r1.

But when I create a new key pair with ECC, sign the public key with
openssl with the same extension file, and try to use it, I get the
following situation

* When I do a kinit, connection is opened to the KDC and it sends the
message "pre-authentication required" back.
* After I enter the yubikey PIN, there is no more communication with
the KDC - so the problem is on the client as Greg has already proposed
* kinit reports that the certificate from the yubikey has been read
and that the CN is OK (I am using pkinit_cert_match...).
* But then, I am getting the following message from opensc:

P:296321; T:0x140609979246400 17:33:26.054 [opensc-pkcs11]
pkcs11-object.c:697:C_SignInit: C_SignInit() = CKR_KEY_HANDLE_INVALID

So there is some problem with opensc-pkcs11. Interestingly I am using
the same Yubikey successfully with pam-pkcs11 to authenticate without
problems.

I have some hope that I am seeing a configuration issue, even though it
is weird that this would depend on the public key algorithm.

On 11/17/23 06:53, Greg Hudson wrote:
> On 11/15/23 23:22, Goetz Golla wrote:
>> * Does MIT Kerberos support PKINIT with Elliptic Curves as described
>> in RFC 5349 ?
>
> A P-384 EC client certificate works in my tests, with either krb5-1.17
> or the current code, as long as the KDC is also running MIT krb5.
>
> Ken is correct that there is a hardcoded reference to RSA in the source:
>
>         p7si->digest_enc_alg->algorithm =
>             OBJ_nid2obj(NID_sha256WithRSAEncryption);
>
> and this probably means the CMS signature has a piece of incorrect
> metadata when an EC certificate is used.  But this field is not used
> when generating the signature contents and is ignored by OpenSSL when
> verifying the signature (when the KDC is running MIT krb5).
>
>> * Could it be that for ECC client certificates the KDC certificate
>> also needs the be ECC ?
>
> In my tests the KDC certificate was an RSA cert, so no.
>
> Of course, my experience doesn't match yours.  From your trace, I
> believe that the failure occurs in the client code, not on the KDC, so
> inspecting the KDC logs would not help.  But the trace log does not
> contain any detailed information about the failure.
>
> You can sometimes improve the diagnostics for PKINIT failures by
> removing the long-term keys associated with the principal, so that
> authentication does not fall back to encrypted timestamp:
>
>   kadmin purgekeys -all user
>
> If that doesn't help, it may be necessary to build the code with
> debugging symbols and and step through it to find out where it is
> failing.

1
server_pubkey.txt

rocksolid light 0.9.8
clearnet tor