On Tue, Apr 29, 2025 at 01:48:21PM +0000, Douglas Gash (dcmgash) wrote:
> PROPOSED NEW TEXT:
>
> For the client-side validation of presented TLS TACACS+ server
> identities, implementations MUST follow [RFC9525] validation
> techniques. Identifier types DNS-ID, IP-ID, or SRV-ID are applicable
> for use with the TLS TACACS+ protocol, selected by operators
> depending upon the deployment design. TLS TACACS+ does not use URI-
> IDs for TLS TACACS+ server identity verification.
>
> Wildcards in TLS TACACS+ server identities simplify certificate
> management by allowing a single certificate to secure multiple
> servers in a deployment. However, this introduces security risks, as
> compromising the private key of a wildcard certificate impacts all
> servers using it. To address these risks, the guidelines in
> Section 6.3 of [RFC9525] MUST be followed, and the wildcard
> SHOULD be confined to a subdomain dedicated solely to
> TLS TACACS+ servers.
Shared private key compromise isn't the only risk of wildcard
certificates, it is also possible for active MiTM attacks or DNS cache
poisoning to transparently redirect connections between the various
devices that share a wildcard certificate, an operator or automated
script might then make configuration changes to the wrong device.
Also replacement of wildcard certificates is often performed in concert
across all the devices that share the certificate, creating a potential
single point of failure.
Even if wildcards are supported, they should at least be discouraged.
How common is use of wildcard certificates in this context? Are they
really needed? Or is this "convenience" a marginal behaviour to avoid?
--
Viktor.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
