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

[tirumal reddy <[e-mail]>]

Hi Russ,

Please see inline

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