From nobody Tue Aug 23 09:57:57 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 0E63EC14F75F for ; Tue, 23 Aug 2022 09:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 d7aiS6puT3lC for ; Tue, 23 Aug 2022 09:57:54 -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 F3B1AC14F73B for ; Tue, 23 Aug 2022 09:57:53 -0700 (PDT) Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id C932118EAF5; Tue, 23 Aug 2022 12:57:52 -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 A3C55191DE6; Tue, 23 Aug 2022 12:57:52 -0400 (EDT) From: Russ Housley Message-Id: <9900F976-524C-4156-ADE4-05BC66466E06@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6670C42B-8846-4BDD-B38E-64178F01F0AF" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Tue, 23 Aug 2022 12:57:52 -0400 In-Reply-To: Cc: tirumal reddy , Tomas Gustavsson , LAMPS To: "Peinado, German (Nokia - PL/Wroclaw)" References: <2404FB76-F49E-4DBE-A8F9-7655EE210440@vigilsec.com> <21CFD228-67C6-407E-A09F-EA17804F4E45@vigilsec.com> <429F80EE-FCF6-4403-9526-8CF8FED26A04@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: Tue, 23 Aug 2022 16:57:56 -0000 --Apple-Mail=_6670C42B-8846-4BDD-B38E-64178F01F0AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the reply. Agreed. Russ > On Aug 23, 2022, at 12:53 PM, Peinado, German (Nokia - PL/Wroclaw) = wrote: >=20 > Russ: > =20 > SA3 meeting is ongoing, and it is an e-meeting. Let=E2=80=99s wait = until the end of the week when the meeting finishes. > =20 > Thanks, > German > =20 > From: Russ Housley >=20 > Sent: Tuesday, August 23, 2022 5:50 PM > To: Peinado, German (Nokia - PL/Wroclaw) > > Cc: tirumal reddy >; = Tomas Gustavsson >; LAMPS > > Subject: Re: [lamps] Call for adoption of = draft-housley-lamps-3g-nftypes > =20 > German: > =20 > Has the discussion taken place? If not, how much additional time is = needed? > =20 > Russ > =20 >=20 >=20 > On Aug 11, 2022, at 7:40 AM, Peinado, German (Nokia - PL/Wroclaw) = > wrote: > =20 > Russ:=20 > =20 > Thanks for the feedback. > =20 > Regarding my request on letting SA3 to discuss this draft and = consequently to postpone the current deadline to the support or = opposition to adoption of the draft, does it sound reasonable and = beneficial? > =20 > Thanks, > German > =20 > From: Russ Housley >=20 > Sent: Wednesday, August 10, 2022 5:37 PM > To: Peinado, German (Nokia - PL/Wroclaw) > > Cc: tirumal reddy >; = Tomas Gustavsson >; LAMPS > > Subject: Re: [lamps] Call for adoption of = draft-housley-lamps-3g-nftypes > =20 > =20 > German: > =20 > Yes, I agree that clear that this extension is expected yo bu used in = a PKI that is internal to the 5G provider. > =20 > Russ > =20 >=20 >=20 >=20 > On Aug 10, 2022, at 3:34 AM, Peinado, German (Nokia - PL/Wroclaw) = > wrote: > =20 > Dear All,=20 > =20 > My name is German Peinado, and I work in Nokia as SA3 delegate in = 3GPP. As rapporteur of the new SID TR 33.876 in rel-18 this topic = caught. > =20 > I agree with Tomas in his observation related to publicly trusted = WebPKI CAs vs. internal CAs typically used in 3GPP networks. Thus, it = would be good to make this assumption explicit in the draft as suggested = by Tiru.=20 > =20 > The relevant document for the guard related to the usage of vendor = certificate is TS 33.310 (NDS;AF). However this guard is not really = applicable or valid in SBA scenario for 5G Core Network Functions that = are basically virtual network functions. The usage of vendor = certificates as trust anchor to establish initial trust with the CA was = designed for base stations in LTE times, and adopted in 5G for physical = base stations. This is an issue we are currently studying in the TR = 33.876.=20 > =20 > The overall draft looks quite straightforward, and of course relevant = for the 5G Network Functions. A colleague from Ericsson in SA3 is = proposing a discussion paper in upcoming SA3 meeting in 22nd -26th of = August where this paper is mentioned to address one current format = issue. Since this draft addresses a valid topic related to the certs = used in 5G network functions as specified in 3GPP, I would kindly ask to = this group to give at least one round of discussions in SA3 on this = draft in the upcoming SA3 meeting, and consequently to postpone by a few = weeks the current deadline (22.08) to voice the support or opposition to = adoption of the draft. That way, you would receive feedback on that from = SA3.=20 > =20 > Does it make sense for the group? > =20 > Thanks,=20 > German > =20 > =20 > From: Spasm > = On Behalf Of tirumal reddy > Sent: Wednesday, August 10, 2022 8:55 AM > To: Tomas Gustavsson > > Cc: Russ Housley >; = LAMPS > > Subject: Re: [lamps] Call for adoption of = draft-housley-lamps-3g-nftypes > =20 > On Wed, 10 Aug 2022 at 12:02, Tomas Gustavsson = > = 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. > =20 > Thanks. Please update the draft to say the deployment model uses an = internal CA and not a public WebPKI CA. > =20 > =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 > A pointer to the relevant document will be helpful. > =20 > -Tiru > =20 > =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 > =20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm = --Apple-Mail=_6670C42B-8846-4BDD-B38E-64178F01F0AF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for the reply.  Agreed.

Russ


On Aug 23, 2022, at 12:53 PM, Peinado, German (Nokia - = PL/Wroclaw) <german.peinado@nokia.com> wrote:

Russ:
 
SA3 meeting is ongoing, and it is an e-meeting. Let=E2=80=99s = wait until the end of the week when the meeting finishes.
 
Thanks,
German
 
From: Russ Housley <housley@vigilsec.com> 
Sent: Tuesday, August 23, 2022 = 5:50 PM
To: Peinado, German (Nokia - = PL/Wroclaw) <german.peinado@nokia.com>
Cc: tirumal reddy <kondtir@gmail.com>; Tomas Gustavsson = <Tomas.Gustavsson@keyfactor.com>; LAMPS <spasm@ietf.org>
Subject: Re: [lamps] Call for = adoption of draft-housley-lamps-3g-nftypes
 
German:
 
Has = the discussion taken place?  If not, how much additional time is = needed?
 
Russ
 


On Aug 11, 2022, at 7:40 AM, Peinado, = German (Nokia - PL/Wroclaw) <german.peinado@nokia.com> = wrote:
 
Russ: 
 
Thanks = for the feedback.
 
Regarding my request on letting SA3 to = discuss this draft and consequently to postpone the current deadline to = the support or opposition to adoption of the draft, does it sound = reasonable and beneficial?
 
Thanks,
German
 
From: Russ Housley <housley@vigilsec.com> 
Sent: Wednesday, August 10, 2022 = 5:37 PM
To: Peinado, German (Nokia - = PL/Wroclaw) <german.peinado@nokia.com>
Cc: tirumal reddy <kondtir@gmail.com>; Tomas Gustavsson = <Tomas.Gustavsson@keyfactor.com>; LAMPS <spasm@ietf.org>
Subject: Re: [lamps] Call for = adoption of draft-housley-lamps-3g-nftypes
 
 
German:
 
Yes, I agree that clear = that this extension is expected yo bu used in a PKI that is internal to = the 5G provider.
 
Russ
 



On Aug 10, 2022, at 3:34 AM, Peinado, German = (Nokia - PL/Wroclaw) <german.peinado@nokia.com> wrote:
 
Dear All, 
 
My name is German Peinado, = and I work in Nokia as SA3 delegate in 3GPP. As rapporteur of the new = SID TR 33.876 in rel-18 this topic caught.
 
I agree with Tomas in his = observation related to publicly trusted WebPKI CAs vs. internal CAs = typically used in 3GPP networks. Thus, it would be good to make this = assumption explicit in the draft as suggested by Tiru. 
 
The relevant document for = the guard related to the usage of vendor certificate is TS 33.310 = (NDS;AF). However this guard is not really applicable or valid in SBA = scenario for 5G Core Network Functions that are basically virtual = network functions. The usage of vendor certificates as trust anchor to = establish initial trust with the CA was designed for base stations in = LTE times, and adopted in 5G for physical base stations. This is an = issue we are currently studying in the TR 33.876. 
 
The overall draft looks = quite straightforward, and of course relevant for the 5G Network = Functions. A colleague from Ericsson in SA3 is proposing a discussion = paper in upcoming SA3 meeting in 22nd -26th of = August where this paper is mentioned to address one current format = issue. Since this draft addresses a valid topic related to the certs = used in 5G network functions as specified in 3GPP, I would kindly ask to = this group to give at least one round of discussions in SA3 on this = draft in the upcoming SA3 meeting, and consequently to postpone by a few = weeks the current deadline (22.08) to voice the support or opposition to = adoption of the draft. That way, you would receive feedback on that from = SA3. 
 
Does it make sense for the = group?
 
Thanks, 
German
 
 
From: Spasm = <spasm-bounces@ietf.org> On Behalf = Of tirumal = reddy
Sent: Wednesday, August 10, 2022 = 8:55 AM
To: Tomas Gustavsson <Tomas.Gustavsson@keyfactor.com>
Cc: Russ = Housley <housley@vigilsec.com>; LAMPS <spasm@ietf.org>
Subject: Re: [lamps] Call for = adoption of draft-housley-lamps-3g-nftypes
 
On Wed, 10 Aug 2022 at = 12:02, 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.
 
Thanks. Please update the = draft to say the deployment model uses an internal CA and not a = public WebPKI CA.
 
 
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.
 
A pointer to the = relevant document will be helpful.
 
-Tiru
 
 
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
 
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

= --Apple-Mail=_6670C42B-8846-4BDD-B38E-64178F01F0AF--