From nobody Wed Aug 10 08:51:15 2022 Return-Path: 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 ; 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 ; 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 ; 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 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: Cc: tirumal reddy , LAMPS To: Tomas Gustavsson References: <2404FB76-F49E-4DBE-A8F9-7655EE210440@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.21) X-Scanned-By: mailmunge 3.09 on 66.39.134.11 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2022 15:51:14 -0000 --Apple-Mail=_FE76CE53-7AF0-47BE-AB6F-AF2E9AE171AB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 = wrote: >=20 > 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. >=20 > 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. >=20 > Cheers, > Tomas >=20 > From: Spasm > = on behalf of tirumal reddy > > Sent: Wednesday, August 10, 2022 7:22 AM > To: Russ Housley > > Cc: LAMPS > > Subject: Re: [lamps] Call for adoption of = draft-housley-lamps-3g-nftypes > =20 > CAUTION: External Sender - Be cautious when clicking links or opening = attachments. Please email InfoSec@keyfactor.com = with any questions. >=20 > Hi Russ, >=20 > Please see inline >=20 > On Mon, 8 Aug 2022 at 21:01, Russ Housley > wrote: > Tiru: >=20 >> 1. Yes, this is a good topic to expand the Security Considerations. >>=20 >> 2. This seems pretty obvious to me, but I will think about a sentence = or two for a more complete explanation. >>=20 >> 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 ?=20 >=20 > Yes, the certificate is plaintext when TLS 1.2 is used, and it it = encrypted when TLS 1.3 or IKEv2 is used. >=20 > 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. > =20 >=20 > 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? >=20 > No, trusted CA may not inject a wrong NFType and it can be validated = by the network function sending the CSR to the CA.=20 > 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. >=20 > Cheers, > -Tiru=20 >=20 > Russ --Apple-Mail=_FE76CE53-7AF0-47BE-AB6F-AF2E9AE171AB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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> on behalf of tirumal reddy = <kondtir@gmail.com>
Sent: Wednesday, August 10, 2022 = 7:22 AM
To: Russ Housley <housley@vigilsec.com>
Cc: LAMPS= <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 with any = questions.

Hi Russ,

Please see inline

On Mon, = 8 Aug 2022 at 21:01, Russ Housley <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

= --Apple-Mail=_FE76CE53-7AF0-47BE-AB6F-AF2E9AE171AB--