Re: [lamps] Call for adoption of draft-housley-lamps-3g-nftypes

Russ Housley <housley@vigilsec.com> Wed, 10 August 2022 15:51 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54BA2C15C53A for <spasm@ietfa.amsl.com>; Wed, 10 Aug 2022 08:51:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 h5aiGvDagI21 for <spasm@ietfa.amsl.com>; Wed, 10 Aug 2022 08:51:10 -0700 (PDT)
Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C067FC14F72A for <spasm@ietf.org>; Wed, 10 Aug 2022 08:51:10 -0700 (PDT)
Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id B84B1EEA43; Wed, 10 Aug 2022 11:51:07 -0400 (EDT)
Received: from [10.0.1.2] (pfs.iad.rg.net [198.180.150.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id 5651CEEAA3; Wed, 10 Aug 2022 11:51:07 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <1C3D4DD2-A57F-4989-8257-DE982963F2A6@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FE76CE53-7AF0-47BE-AB6F-AF2E9AE171AB"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
Date: Wed, 10 Aug 2022 11:51:06 -0400
In-Reply-To: <DU0PR03MB86963D63921A321097313CDE86659@DU0PR03MB8696.eurprd03.prod.outlook.com>
Cc: tirumal reddy <kondtir@gmail.com>, LAMPS <spasm@ietf.org>
To: Tomas Gustavsson <Tomas.Gustavsson@keyfactor.com>
References: <DM8PR14MB52376D8E7F6F414563238A18839F9@DM8PR14MB5237.namprd14.prod.outlook.com> <CAFpG3gciz2h+wTCnWy0Uazn+CLSKhWaCRnk6tNtptZriVtvseA@mail.gmail.com> <E1C193C7-F876-4F18-8AD8-8548F4BFA983@vigilsec.com> <CAFpG3geF2jxoMZfeXO9hLM+9z6Ovsn59eBhYYmEez7A=AfF4eA@mail.gmail.com> <2404FB76-F49E-4DBE-A8F9-7655EE210440@vigilsec.com> <CAFpG3gdq-O7-bqXFyLkQ0Rd8YW_G9WZkaii-__rBuA3MFbnPRg@mail.gmail.com> <DU0PR03MB86963D63921A321097313CDE86659@DU0PR03MB8696.eurprd03.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.21)
X-Scanned-By: mailmunge 3.09 on 66.39.134.11
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/B6XyIZkJhOuvGBttjb_1mK1ryJI>
Subject: Re: [lamps] Call for adoption of draft-housley-lamps-3g-nftypes
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Aug 2022 15:51:14 -0000

Tiru and Tomas:

I understand the privacy concern about the CT logs that you are raising.  However, I do not think that a policy statement about the inclusion or exclusion of 5G system certificates in CT Logs belongs in the document that defines the NFTypes extension.

Russ

> On Aug 10, 2022, at 2:32 AM, Tomas Gustavsson <Tomas.Gustavsson@keyfactor.com> wrote:
> 
> I don't think 3GPP networks will make use of certificate transparency logs. These are internal telco networks and will not use publicly trusted WebPKI CAs for issuing TLS certificates. I don't think publicly trusted CAs could even issue these certificates as it may contain other information than what's allowed by Baseline Requirements, such as internal hostnames/IPs.
> 
> There are some guards against malicious network functions built into the 3GPP specification, by the usage of vendor certificates for authenticating the network functions the MNO plans to put into it's network.
> 
> Cheers,
> Tomas
> 
> From: Spasm <spasm-bounces@ietf.org <mailto:spasm-bounces@ietf.org>> on behalf of tirumal reddy <kondtir@gmail.com <mailto:kondtir@gmail.com>>
> Sent: Wednesday, August 10, 2022 7:22 AM
> To: Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com>>
> Cc: LAMPS <spasm@ietf.org <mailto:spasm@ietf.org>>
> Subject: Re: [lamps] Call for adoption of draft-housley-lamps-3g-nftypes
>  
> CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email InfoSec@keyfactor.com <mailto:InfoSec@keyfactor.com> with any questions.
> 
> Hi Russ,
> 
> Please see inline
> 
> On Mon, 8 Aug 2022 at 21:01, Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com>> wrote:
> Tiru:
> 
>> 1. Yes, this is a good topic to expand the Security Considerations.
>> 
>> 2. This seems pretty obvious to me, but I will think about a sentence or two for a more complete explanation.
>> 
>> Thanks. You may want to also discuss the privacy and security implications of using NFType in the certificate extension for RBAC. For example (1) If TLS 1.2 is used by network functions, pervasive monitoring is possible for an attacker to identify the NFTypes visible in the TLS handshake and can potentially target a specific NFType (e.g., subject to DDoS or launch a targeted attack). (3) Misuse of NFType to gain additional privileges and what are the potential remediation techniques ? 
> 
> Yes, the certificate is plaintext when TLS 1.2 is used, and it it encrypted when TLS 1.3 or IKEv2 is used.
> 
> In TLS 1.3 (without encrypted client hello), SNI will not be encrypted and it is possible for an attacker to get the certificate content from certificate transparency logs to identify the NFTypes associated with the FQDN.
>  
> 
> I'm not sure what you mean about misuse of the NFType.  Are you talking about the trusted CA putting the wrong NFType in the certificate?
> 
> No, trusted CA may not inject a wrong NFType and it can be validated by the network function sending the CSR to the CA. 
> I meant the NFTypes and FQDN of network functions will be available in the certificate transparency logs. It exposes the internal/external network functions details to anyone on the Internet. It may also be possible for an internal attacker to host a malicious network function and misuse the NFType to gain additional privileges.
> 
> Cheers,
> -Tiru 
> 
> Russ