Re: [Anima] ANIMA: Certificate authentication, BRSKI PRM and RFC8995
"Fries, Steffen" <steffen.fries@siemens.com> Thu, 04 May 2023 18:10 UTC
Return-Path: <steffen.fries@siemens.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A57C17B329; Thu, 4 May 2023 11:10:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=siemens.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-ZNdScKyjbB; Thu, 4 May 2023 11:10:31 -0700 (PDT)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2062e.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DDE7C17B32B; Thu, 4 May 2023 11:08:37 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KCFjpFc1dxaESqpHXLtLY+T/ig6JTLKi/OGyLoB/tBBu31DuLwN20mGVn0oVRoipLGZkRqAjjN3IRPE2pZGn2ez6I2fjISIBCgH1KfFh1MIk8plOXrcY1jGp7HPRTyIF9e2/M481gwjpSYf3fA33KDpUbzqs0vqkYQ10H30JgcTYEKhkcU3qF//fdb4CGwADS5nAzDpTRPK0BuIHG9PYP3/5mPPk0rDRQaeVU1sWKgiJSpqISfGatlr529F5Wz8zA0b/ovrSGT5YYivAEUsXleH5fOr4ZK9YuPkcHcpeY0/uCIWdGPIWJ6wXD9jVls1c9xkxwfXbPXxRQPI7fBm/7Q==
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=qcpqmLs0DmetZ1cvLM6yCfbirUhfaZ6yl5+UNjEEJIU=; b=lTcAxjJX5f3RCCJItNioejmxg/geQKB6B1uPej/+yUOOAMdXWGdu30SrK+jdh4HV5FsnVkRqm2RWjcdVrCAz0QSIaXTEBb8QDd4w08HUeOE5Hq9ruuT1c3Yg5Tq48HmxZm//y/Tf8/VV3ks3PvEsFEE46TGACt7d1NV670XuJqp6KZQD3o8oKlJXUX5h9udE9Txg2xtL5NpZXGchmDzsSa80pZQdsUdFZVm1DsD5F3WAw7TW4X4Gzj6DLLVFRUYyqNO7On8FJ0+urUaELL5njHJxKrIxfxsSWiSlfXe0PSTWmkDujQCW3hyGP/CvTlSy4s/m8puqgsE4xc2LPiabjA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qcpqmLs0DmetZ1cvLM6yCfbirUhfaZ6yl5+UNjEEJIU=; b=RPYrefPZq6ewkl9wLm8QDcTUHQC7FYiUYfkUhffKLxq65jFoZ2o9ti9J7YpHrWMN4hlI3L8XwmtEKqoo9Dwvfj7qQCiPq7iji7xJBRTkpUE6FO/wPbwNPzaPBbVUZtsox2Zb58ah53tT7TbWcgtZgPVR6a2zn3ELjF0U7Q+PJtnBNLRQ3FoBVFN9Jix8KXl+ApuRQFvbucxhulnEUe4oRMcq6TUfhzzpWyzOu6TfVNRs7E+htDizL5jEevhnMZ5rv5hMHQylPK1ZyxwTQL6fZApm3qCEcKGQqVkfDiZwfLNL+o60vDaGTWyIKr6CEuhSvCyUlcddWZ57/onarD8ecg==
Received: from DB9PR10MB6354.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:10:3c6::22) by AS8PR10MB7374.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:616::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6363.26; Thu, 4 May 2023 18:08:31 +0000
Received: from DB9PR10MB6354.EURPRD10.PROD.OUTLOOK.COM ([fe80::74c:c281:eacb:8240]) by DB9PR10MB6354.EURPRD10.PROD.OUTLOOK.COM ([fe80::74c:c281:eacb:8240%4]) with mapi id 15.20.6363.022; Thu, 4 May 2023 18:08:31 +0000
From: "Fries, Steffen" <steffen.fries@siemens.com>
To: Esko Dijk <esko.dijk@iotconsultancy.nl>, Toerless Eckert <tte@cs.fau.de>, "anima@ietf.org" <anima@ietf.org>
CC: "draft-t2trg-idevid-considerations@ietf.org" <draft-t2trg-idevid-considerations@ietf.org>
Thread-Topic: [Anima] ANIMA: Certificate authentication, BRSKI PRM and RFC8995
Thread-Index: AQHZeGIe1XSORC2SXUiM2b7qw8jNVq8/sImAgADXahCACexPIA==
Date: Thu, 04 May 2023 18:08:31 +0000
Message-ID: <DB9PR10MB6354F6A0ED8ABA369491683BF36D9@DB9PR10MB6354.EURPRD10.PROD.OUTLOOK.COM>
References: <ZElbI1fFuPUqyTyD@faui48e.informatik.uni-erlangen.de> <DU0P190MB1978CD4A91F2EE68A4998B4BFD6A9@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <DB9PR10MB63541F85EAB794E0D9219F4DF36F9@DB9PR10MB6354.EURPRD10.PROD.OUTLOOK.COM>
In-Reply-To: <DB9PR10MB63541F85EAB794E0D9219F4DF36F9@DB9PR10MB6354.EURPRD10.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_Enabled=true; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_SetDate=2023-05-04T18:08:27Z; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_Method=Standard; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_Name=restricted; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_ActionId=c95a0e81-0ce7-4e30-a893-dc6e56af39a7; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_ContentBits=0
document_confidentiality: Restricted
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=siemens.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DB9PR10MB6354:EE_|AS8PR10MB7374:EE_
x-ms-office365-filtering-correlation-id: d3a8a1f1-1eb2-4d11-9824-08db4cca91b9
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 541alZeyKIuGJDlpu5D3aGoSoK6MKO+F/bh/Ke/KsvsODCL2zrMvKbOVsu7QCZJH3lJaYaDHJWBLiNciRSklwepcjtLqD4CZO6WTpHmtECP1WWGGXZAv1EiBBtfdOxP7FqdOcwVHGul1ZTZoB/af6jZOFh+SavqY4WpLfbNsw5XLV2Ab8oo+Iv+i7NTATp9XR5JuEqxkEsy46p6ipBTkNsn2U2I2jxH98AHI7iYT9KyTYCAFwD/l8xK3Mln+vl0mzeLv4Ecy3fYP8XrOHXL5j7jtZWl8tmN7L9bdvb4VImG1hh/ScIeNJRVTHxgpdHIIbheAWoqfN2XkGYP6PIirfuWjmuCGskHbtGw7DCOMubmyBfa7+gfFImggMePZLt85CZWUr42uAFJlnG+GJhstJHaJGZXtT8ePZ+i24kdzRESmQWKw2mUJ6Q+I2KdyPQa/YCcDfSgoJyEcCvRwzyjLvSVx2R0qfI+5VYZPNTv8sbcWdvgnzQ+BCSFjz4uAH2fP4ZoBv167R9tHxHpLyCl2Sn0w1JARHtQdEzHeTveBfJC1w4vk8KLP313asid0u7CNwA9f5cUpd5AaYFTGLByDvAVOHrtSE+o+vgw02iJAuTY=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB9PR10MB6354.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230028)(4636009)(136003)(376002)(396003)(366004)(346002)(39860400002)(451199021)(478600001)(110136005)(33656002)(45080400002)(30864003)(2906002)(66899021)(52536014)(5660300002)(8676002)(8936002)(41300700001)(76116006)(66946007)(316002)(64756008)(66446008)(66476007)(66556008)(4326008)(38070700005)(71200400001)(55016003)(966005)(7696005)(186003)(26005)(9686003)(6506007)(53546011)(83380400001)(38100700002)(86362001)(122000001)(82960400001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: giARy+/wRpYe70DgczdBMCfs0SUeFkNIKZ069Dcuy6s0L+dJV43U/kyOTSVIsdjUEl1daoCAXD4kMICiOGB2UTpXnSo38740TZYJvMScSKdT+H+E5THfkdUY/J6C5xeU2OMVtjfL2q4/EQw6UroGQVVEYZ7DTDe5AFPNsR3Io9NqkJ1Le8rHdYO5zw3Kjg02M0AOcQh9przkZje2X0mtSSrjkK0nhECVWMfu6Mci+EJVUq3+HxXrdtEAjzx6HTQ3sg8HQpJm2iNONKAeMc0Ej5AA3QTBYPZZyXhI9DqUsMh12GPFanLlfE7ZBsi757R6AzRptvNHQPDq6wASGp8EPC7C9VOb8c3bVfX2dK/oWQ1S8TDi6UquWoFgi/I9PzWQvsjP+SKGFCacqY0YNDCvfzojKa5MdAd+zLGoaGwUtT6UWRRnyGrMLZrBui1aptu3KyP+1iZzrgPsosSGhOPfDIkmt0FsAUTssh774mB1vsxUhJEoHzay/UyliXHYBVBa/c1UvX2FMEVPlm9ssVfqrJcjhZrsIilzsJ9XND/vDG7yDeIjc/XpbSoei81gX3hj9lHLXZ1hUSg9DO+5VC1TaaE9liwbhcXUMtEHZSC9kDxNFEAwJygE552fxGkJBW4YIUXWDryPYo5YSh44V/rTWzB+YIVWRP+7yFeu+H1ZQ5FPD04NyDPIyZedv6i3LtmSoiSzKX4w3MDntW3BB0Uq/UaEBIlrbMU3CASCO1rgVgetxnkQ97SVADpjme2+AbQVh0CZlGy7mBMPkQ91RdQBWEp78gtpDNDz3jBDoxxBYDtc8AkIV06dn1/FcxMg7cPJocw3rdaw60W5kHZrj3UgLyPYl3rNkvxYeahUzVtx7o6yhb6tXlbd7tSflBu0sCWCC30MS6ELtHrmi22nzcK34cHxXs9kjaJj5CTx1lVyzh/j+BplLRjAg+tAqgphAfsPvYGnOnmKoUQi0c0glnhfEZkRAsmBeciXdGJUdSG2Mcpco4Jicgs+88wvEBZ8XTK+3UABtOB3pZAlc4lOn6Hy+llHzxt8uPDzmNY+QExP3RYGXHuDZlwSx8izlzE+4Zkw/gFScxTmWxhi2Mb6GxMc/XPUyCDfqyhyFnNcNtiebEfNEbyMtfl5zvvybikLsjuFbs1VeX5uKHKnwuI9SB+96PQYiFk+leme0p4PG7hEAGDFV2ECFmKnjva+N6LUwOSvhURoaycBZjdPY0W6XT+/QXTscVjkaueBq9ePbdICKrpqGg9INBSeYCtS9HxXWG2JlyMzPb0RUI/K5klgqp5N80liiRzE3PVb3BoDxHn3WJtVGa20wuOTgzlsC5gn1NiNstuqjK/7SS9UtuM0HDPDvx5JDhHajwrjfJqi14ohB70bxlcJiBUzc7D0LU4qbzNIloIqYEVSKT91+TyqUbHd9k4rzbK9EtYKuTsrryHjtGOaMpnnlD9T4c0fUB73ZAXNS7sofxPCQkOQ9HvHyd809Rqrc9wPNsThhbPakoaRbEnxjyWmcV5Cy4fYhr+rnBJfAMHPKWLSa6l69aVBJd4iekKtI1oFOf6OS6jaUTp6U5Sgzfp9ViTpYDs1fe5AQ0zuKDmUxuZU/xrhtUBbgZwjVw==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: siemens.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DB9PR10MB6354.EURPRD10.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: d3a8a1f1-1eb2-4d11-9824-08db4cca91b9
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2023 18:08:31.4785 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 3+C7qg8u3EP9WEGKd4OKp6IJICRhCxcQroxE9Sp9xut7Bxl38EgLlD77GQ+1KIlQbWSKE4Up7bbF5jAyJIKPD/U/6xd26CEvnMiZRv7KlGM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR10MB7374
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/iI5MbvvGXzufxyd97mikemIZ0Xc>
Subject: Re: [Anima] ANIMA: Certificate authentication, BRSKI PRM and RFC8995
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 May 2023 18:10:36 -0000
Hi Toerless, As discussed in the last Design Team meeting, we agreed to include optional support for TLS between the registrar-agent and the pledge, to protect the communication regarding privacy. Depending on the utilized TLS version, certain information about the pledge may still be visible (TLS 1.2 has the handshake in clear, so the pledge IDevID certificate will be visible during the establishment). On the other hand, as the pledge will accept incoming connections in factory mode, it is also possible the TLS connection is established by a potential active adversary. The optional TLS support has been included in the latest commit on gitlab addressing issue #82 and also #83. Next week we will further discuss remaining open issues in the Design Team Meeting. Best regards Steffen > -----Original Message----- > From: Anima <anima-bounces@ietf.org> On Behalf Of Fries, Steffen > Sent: Dienstag, 2. Mai 2023 07:50 > To: Esko Dijk <esko.dijk@iotconsultancy.nl>; Toerless Eckert <tte@cs.fau.de>; > anima@ietf.org; draft-ietf-anima-prm@ietf.org > Cc: draft-t2trg-idevid-considerations@ietf.org > Subject: Re: [Anima] ANIMA: Certificate authentication, BRSKI PRM and > RFC8995 > > Hi Toerless, Esko, > > After some further discussions and double check of RFC 2818 I agree, it is > possible to omit the hostname verification. > The key I think is the statement in section 3.1 of RFC 2818 > (https://datatrac/ > ker.ietf.org%2Fdoc%2Fhtml%2Frfc2818%23section- > 3.1&data=05%7C01%7Csteffen.fries%40siemens.com%7Cc2662a2ceff649ab93f > e08db4ad110d2%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6381 > 86034047182057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ > QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata > =nzQ4Q4em6jN9yCqrXPNNTMVlCkMD6Ct9Q%2F6wu%2B7Hj5A%3D&reserved= > 0): > If the client has external information as to the expected identity of the > server, the hostname check MAY be omitted. > A similar statement can be found in section 4.3.4 of RFC 9110 > (https://www.rfc/ > -editor.org%2Frfc%2Frfc9110.html%23name-https-certificate- > verificat&data=05%7C01%7Csteffen.fries%40siemens.com%7Cc2662a2ceff649 > ab93fe08db4ad110d2%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7 > C638186034047182057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C > &sdata=Mxr%2F%2BXwUx77bmIJiyfec2hYY5DLF7IvHO6pUZBjuKPo%3D&reserve > d=0) > In special cases, it might be appropriate for a client to simply ignore the > server's identity, but it must be understood that this leaves a connection open to > active attack. > > In case of BRSKI-PRM the identity check of the pledge (as TLS server) may be > done based on the device serial numbers a registrar-agent must possess before > onboarding pledges as outlined in section 6.1 > (https://www.iet/ > f.org%2Farchive%2Fid%2Fdraft-ietf-anima-brski-prm-08.html%23name-request- > objects- > acquisition&data=05%7C01%7Csteffen.fries%40siemens.com%7Cc2662a2ceff6 > 49ab93fe08db4ad110d2%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0% > 7C638186034047182057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C > &sdata=heSaUFyA8n6dno4k3oBYZETpmKFlaxmg4LiBiEDfrV0%3D&reserved=0). > This is in addition to the trustanchor (IDevID CA certificate) the registrar-agent > (TLS client) would need to verify the IDevID certificate of the pledge to ensure > he is connected to the specific instance of the pledge. > > Getting back to the origin of the discussion, as the discussion was a result on > one of the reasoning provided in BRSKI-PRM to not apply TLS between the > registrar-agent and the pledge: > - In BRSKI-PRM the communication between the registrar-agent and the pledge > was designed to not rely on transport security, to enable also alternative > transports such as BTLE or even NFC. For these, the use of TLS was not expected > and therefore security is applied on the messages exchanged directly. > - As BRSKI-PRM targets as first approach for the exchange of the bootstrapping > information to utilize http as transport we could recommend using TLS here to > protect the privacy of the communication. This would only enhance the existing > approach for that specific communication link as TLS is already used between > the registrar-agent and the registrar. > > I will provide a proposal what to change in BRSKI-PRM for discussion in the next > Design Team Meeting (today). > > Best regards > Steffen > > > > -----Original Message----- > > From: Anima <anima-bounces@ietf.org> On Behalf Of Esko Dijk > > Sent: Donnerstag, 27. April 2023 23:46 > > To: Toerless Eckert <tte@cs.fau.de>; anima@ietf.org; draft-ietf-anima- > > prm@ietf.org > > Cc: draft-t2trg-idevid-considerations@ietf.org > > Subject: Re: [Anima] ANIMA: Certificate authentication, BRSKI PRM and > > RFC8995 > > > > Hi Toerless, > > > > I agree with your analysis here. RFC 2818 does allow to omit the > > hostname check if the client has additional information about the > > expected identity of the server. (Which is in the PRM case, the CA > > trust anchors of the manufacturer of the device - or a set of trusted > > manufacturers that the commissioning tool > > tusts.) > > > > Also notice that although EST (RFC 7030) mentions RFC 2818, the > > BRSKI-PRM device to be onboarded does not implement EST server so any > > RFC 7030 requirements on the server are not really applicable for that BRSKI- > PRM device. > > We define a new type of server here (the "Pledge-PRM" TLS server?) > > with own rules. I don't see why it should follow EST server rules > > here, it's not an EST server. > > > > That said, RFC 9110 makes things more restrictive it seems. But it > > also says in 4.3 "However, authoritative access is not limited to the identified > mechanism." > > which means that other means of authoritative access to a > > resource/HTTPS server , i.e. other than the method defined in section 4.3 , are > also foreseen. > > So it should be okay to use HTTPS for the BRSKI-PRM use case. > > > > Regards > > Esko > > > > -----Original Message----- > > From: Anima <anima-bounces@ietf.org> On Behalf Of Toerless Eckert > > Sent: Wednesday, April 26, 2023 19:11 > > To: anima@ietf.org; draft-ietf-anima-prm@ietf.org > > Cc: draft-t2trg-idevid-considerations@ietf.org > > Subject: [Anima] ANIMA: Certificate authentication, BRSKI PRM and > > RFC8995 > > > > In the process of discussing shepherd review feedback for BRSKI-PRM > > draft, the authors brought up arguments relating to their > > interpretation of requirements against required TLS server certificate > validation by the client. > > > > Let me try to hopefully correctly restate and provide my thoughts, if > > i am misrepresenting, please correct me! > > > > Pre: > > > > A pledge has an IDevID and some dynamically assigned IP(v6) address, > > and no domain name. > > > > Claim of the authors > > > > Another device can not build a HTTP over TLS connection to the pledge > > and authenticate the pledge, because of the absence of domain name and > > IP- address based SubjectAltNames in the certificate - according to RFC2818. > > RFC2818 is required to be met because BRSKI relies on RFC7030 and > > RFC7030 requires RFC2818. > > > > My assessment: > > > > I think this is an incorrect reading: I think that any time that a TLS > > server would identify itself with an IDevID, paragraph 2 of section > > 3.1 of RFC2818 would be > > applicable: The "narrow the scope of acceptable certificates" are > > those certificates that can be validted against the trust anchors that the client > trusts. > > E.g.: The trust anchors from the vendor(s) from which the client > > expects the IDevID to be signed. > > > > Furthermore: > > > > I think the very same is also true for BRSKI itself, e.g.: the only > > authentication that pledges are doing against a registrar is > > authenticating the certificate against the trust anchor provided in > > the voucher. There is no additional authentication against any type of > > additional Subject Name or SubjectAltName that the certificate of a registrar > my carry (dns name or ip address). > > > > draft-t2trg-idevid-considerations > > > > I did not have time to read through this draft, but would that > > potentially be a good place to reconfirm that one can build a TLS > > connection to a device that will use it's IDevID to authenticate > > itself, and a secure authentication of that device as a TLS server > > effectively only requires validation of the certificate chain against > > the trust anchor of the menufacturer for the device - no additional verification > of other addresses. > > > > RFC2818 -> RFC9110: > > > > I find these whole HTTP drafts quite confusing: > > > > - RFC2818 was never standards track, but only informational but still > > uses > > RFC2119 terminology > > (MUST / SHOULD / ...). > > > > - RFC2818 was obsoleted by RFC9110. And RFC9110 is now standards track. > > > > - RFC9110 states in section B.1 that it does not changes anything from > RFC2818. > > But then you look at RFC9110 section 4.3.4 and the text is quite different > from > > RFC2818 section 3.1. In fact, i would claim that RFC9110 is even more > WebPKI > > centric written than RFC2818 ("In general, a client MUST verify > > the service identity using the verification process defined in > > Section 6 of > > [RFC6125].") > > Aka: "In General all certificate validation is WebPKI validation".... > > With our non-webPKI uses cases i feel somewhat neglected ;-) > > > > Does this help ? > > > > Cheers > > Toerless > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www/. > > > ietf%2F&data=05%7C01%7Csteffen.fries%40siemens.com%7Cc2662a2ceff649a > b9 > > > 3fe08db4ad110d2%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63 > 8186034 > > > 047182057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV > 2luMzIi > > > LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sVh%2FRwFe > iixj6Kh > > RzUQFB3YKgDsjjoZ%2FpG2z4D8DHkc%3D&reserved=0 > > > .org%2Fmailman%2Flistinfo%2Fanima&data=05%7C01%7Csteffen.fries%40siem > > > ens.com%7C3bf355e2d13d48444efe08db4768e50b%7C38ae3bcd95794fd4adda > > > b42e1495d55a%7C1%7C0%7C638182288078157646%7CUnknown%7CTWFpbGZ > > > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 > > > %3D%7C3000%7C%7C%7C&sdata=BQZ2%2BrJKFSkb0DIS%2B%2B1qPL8QzJZTkZ > > OIsu%2BFfjOCLYg%3D&reserved=0 > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www/. > > > ietf%2F&data=05%7C01%7Csteffen.fries%40siemens.com%7Cc2662a2ceff649a > b9 > > > 3fe08db4ad110d2%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63 > 8186034 > > > 047182057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV > 2luMzIi > > > LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sVh%2FRwFe > iixj6Kh > > RzUQFB3YKgDsjjoZ%2FpG2z4D8DHkc%3D&reserved=0 > > > .org%2Fmailman%2Flistinfo%2Fanima&data=05%7C01%7Csteffen.fries%40siem > > > ens.com%7C3bf355e2d13d48444efe08db4768e50b%7C38ae3bcd95794fd4adda > > > b42e1495d55a%7C1%7C0%7C638182288078157646%7CUnknown%7CTWFpbGZ > > > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 > > > %3D%7C3000%7C%7C%7C&sdata=BQZ2%2BrJKFSkb0DIS%2B%2B1qPL8QzJZTkZ > > OIsu%2BFfjOCLYg%3D&reserved=0 > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf/ > .org%2Fmailman%2Flistinfo%2Fanima&data=05%7C01%7Csteffen.fries%40siem > ens.com%7Cc2662a2ceff649ab93fe08db4ad110d2%7C38ae3bcd95794fd4addab > 42e1495d55a%7C1%7C0%7C638186034047182057%7CUnknown%7CTWFpbGZs > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 > %3D%7C3000%7C%7C%7C&sdata=S1C9Opot0vvm9qI2UjCDYzc%2F7%2FTIvfgN > Y6xyxIg%2FDkM%3D&reserved=0
- [Anima] ANIMA: Certificate authentication, BRSKI … Toerless Eckert
- Re: [Anima] ANIMA: Certificate authentication, BR… Esko Dijk
- Re: [Anima] ANIMA: Certificate authentication, BR… Fries, Steffen
- Re: [Anima] ANIMA: Certificate authentication, BR… Fries, Steffen