Aller au contenu principal

4. Obsolescence de l'obfuscation TACACS+ (Obsolescence of TACACS+ Obfuscation)

Le mécanisme d'obfuscation documenté dans la section 4.5 de [RFC8907] est faible.

L'introduction de l'authentification et du chiffrement TLS dans TACACS+ remplace cet ancien mécanisme, donc l'obfuscation est par la présente obsolète. Cette section décrit comment les clients et serveurs TACACS+ DOIVENT fonctionner concernant le mécanisme d'obfuscation.

Les pairs NE DOIVENT PAS (MUST NOT) utiliser l'obfuscation avec TLS.

Un client TACACS+ initiant une connexion TACACS+ TLS DOIT (MUST) définir le bit TAC_PLUS_UNENCRYPTED_FLAG, affirmant ainsi que l'obfuscation n'est pas utilisée pour la session. Tous les paquets suivants DOIVENT (MUST) avoir le bit TAC_PLUS_UNENCRYPTED_FLAG défini à 1.

Un serveur TACACS+ TLS qui reçoit un paquet avec le bit TAC_PLUS_UNENCRYPTED_FLAG non défini à 1 sur une connexion TLS DOIT (MUST) retourner une erreur de TAC_PLUS_AUTHEN_STATUS_ERROR, TAC_PLUS_AUTHOR_STATUS_ERROR, ou TAC_PLUS_ACCT_STATUS_ERROR selon le type de message TACACS+, avec le bit TAC_PLUS_UNENCRYPTED_FLAG défini à 1, et terminer la session.

Un client TACACS+ qui reçoit un paquet avec le bit TAC_PLUS_UNENCRYPTED_FLAG non défini à 1 DOIT (MUST) terminer la session et DEVRAIT (SHOULD) enregistrer cette erreur.

5. Considérations de sécurité (Security Considerations)

5.1. TLS​

Ce document améliore la confidentialité, l'intégrité et l'authentification de la connexion et du trafic réseau entre les pairs TACACS+ en ajoutant le support TLS.

Le simple ajout du support TLS au protocole ne garantit pas la protection du serveur et des clients TACACS+ TLS. Il est essentiel que les opérateurs et les fournisseurs d'équipements adhèrent aux dernières meilleures pratiques pour garantir l'intégrité des dispositifs réseau et sélectionner des algorithmes de chiffrement et de clés TLS sécurisés.

[BCP195] offre des conseils substantiels pour l'implémentation et le déploiement de protocoles qui utilisent TLS. Ceux qui implémentent et déploient Secure TACACS+ doivent adhérer aux recommandations relatives à TLS 1.3 décrites dans [BCP195] ou ses versions ultérieures.

5.1.1. Utilisation de TLS (TLS Use)​

Les nouveaux déploiements de production TACACS+ DEVRAIENT (SHOULD) utiliser l'authentification et le chiffrement TLS.

Les serveurs TACACS+ TLS (tels que définis dans la section 2) NE DOIVENT PAS (MUST NOT) autoriser les connexions non-TLS, en raison de la menace d'attaques de rétrogradation ou de mauvaise configuration décrite dans la section 5.3. Au lieu de cela, des serveurs TACACS+ non-TLS séparés DEVRAIENT (SHOULD) être configurés pour répondre à ces clients.

Il N'EST PAS RECOMMANDÉ (NOT RECOMMENDED) que les serveurs TACACS+ TLS et les serveurs TACACS+ non-TLS soient déployés sur le même hôte, pour les raisons discutées dans la section 5.3. Les connexions non-TLS seraient mieux servies en déployant les serveurs TACACS+ non-TLS requis sur des hôtes séparés.

Les clients TACACS+ NE DOIVENT PAS (MUST NOT) revenir à une connexion non-TLS si une connexion TLS échoue. Cette interdiction inclut pendant la migration d'un déploiement (section 6.1).

5.1.2. TLS 0-RTT​

Les techniques de reprise et PSK de TLS 1.3 permettent d'envoyer des données précoces, c'est-à-dire des données 0-RTT, des données qui sont envoyées avant que la poignée de main TLS ne se termine. La relecture de ces données est un risque. Étant donné la sensibilité des données TACACS+, les clients NE DOIVENT PAS (MUST NOT) envoyer de données avant que la poignée de main TLS complète ne se termine; c'est-à-dire que les clients NE DOIVENT PAS (MUST NOT) envoyer de données 0-RTT et les serveurs TACACS+ TLS DOIVENT (MUST) déconnecter brusquement les clients qui le font.

Les clients et serveurs TACACS+ TLS NE DOIVENT PAS (MUST NOT) inclure l'extension early_data. Voir les sections 2.3 et 4.2.10 de [RFC8446] pour les préoccupations de sécurité.

5.1.3. Options TLS (TLS Options)​

Les recommandations de [BCP195] DOIVENT (MUST) être suivies pour déterminer quelles versions et algorithmes TLS devraient être pris en charge, dépréciés, obsolètes ou abandonnés.

De plus, la section 9 de [RFC8446] prescrit les options obligatoires prises en charge.

5.1.4. Autorité de certification (CA) inaccessible (Unreachable Certificate Authority)​

Les opérateurs devraient être conscients du potentiel d'isolement du serveur et/ou du client TACACS+ TLS de la CA de leur pair par des pannes réseau. L'isolement de la CA d'un certificat de clé publique entraînera l'échec de la vérification du certificat et donc l'échec de l'authentification TLS du pair. L'approche mentionnée dans la section 3.4.1 peut aider à résoudre ce problème et devrait être envisagée.

5.1.5. Indicateur de nom de serveur TLS (SNI) (TLS Server Name Indicator)​

Les opérateurs devraient être conscients que l'extension TLS SNI fait partie du client hello TLS, qui est envoyé en clair. Il est donc soumis à l'écoute clandestine. Voir également la section 11.1 de [RFC6066].

5.1.6. Caractères génériques d'identité de serveur (Server Identity Wildcards)​

L'utilisation de caractères génériques dans les identités de serveur TLS crée un point de défaillance unique: une clé privée compromise d'un certificat générique impacte tous les serveurs qui l'utilisent. Leur utilisation DOIT (MUST) suivre les recommandations de la section 7.1 de [RFC9525]. Les opérateurs DOIVENT (MUST) s'assurer que le caractère générique est limité à un sous-domaine dédié exclusivement aux serveurs TACACS+ TLS.

5.2. Configuration TACACS+ (TACACS+ Configuration)​

Les implémenteurs doivent s'assurer que le schéma de configuration introduit pour activer TLS est simple et ne laisse aucune place à l'ambiguïté quant à savoir si TLS ou non-TLS sera utilisé entre le client TACACS+ et le serveur TACACS+.

Ce document recommande l'utilisation d'un numéro de port séparé que les serveurs TACACS+ TLS écouteront. Lorsque les déploiements n'ont pas explicitement remplacé les valeurs par défaut, les implémentations de clients TACACS+ DOIVENT (MUST) utiliser les valeurs de port correctes:

  • Port 49: pour la connexion TACACS+ non-TLS
  • Port 300: pour la connexion TACACS+ TLS

Les implémenteurs peuvent offrir une option unique pour les clients et serveurs TACACS+ afin de désactiver toutes les opérations TACACS+ non-TLS. Lorsqu'elle est activée sur un serveur TACACS+, il ne répondra à aucune demande provenant de connexions de clients TACACS+ non-TLS. Lorsqu'elle est activée sur un client TACACS+, il n'établira aucune connexion de serveur TACACS+ non-TLS.

Une mauvaise configuration courante consiste à activer TLS sur le serveur mais à mal configurer le client pour utiliser le port non-TLS, ou vice versa. Pour éviter cela, les pratiques de configuration claires DEVRAIENT (SHOULD) inclure:

  • Des indicateurs de mode TLS/non-TLS explicites dans les fichiers de configuration
  • Des avertissements de validation lorsque les numéros de port ne correspondent pas au mode configuré
  • Des sections de configuration séparées pour les serveurs TLS et non-TLS

5.3. Numéro de port TCP/IP bien connu (Well-Known TCP/IP Port Number)​

Un nouveau numéro de port est considéré comme approprié (plutôt qu'un mécanisme qui négocie une mise à niveau à partir d'une connexion TACACS+ non-TLS initiale) car il permet:

  • la facilité de bloquer les connexions non obfusquées ou obfusquées par le numéro de port TCP/IP,
  • les systèmes de détection d'intrusion (IDS) passifs surveillant les non obfusqués de ne pas être affectés par l'introduction de TLS,
  • l'évitement des attaques en chemin qui peuvent interférer avec la mise à niveau, et
  • la prévention de l'exposition accidentelle d'informations sensibles en raison d'une mauvaise configuration.

6. Considérations opérationnelles (Operational Considerations)

6.1. Migration (Migration)​

Afin de faciliter une transition en douceur des déploiements TACACS+ hérités vers TACACS+ sécurisé par TLS, les organisations doivent planifier leur migration avec soin. Les stratégies de migration les plus courantes sont:

Fonctionnement parallèle (Parallel Operation): Les opérateurs peuvent déployer de nouveaux serveurs TACACS+ TLS aux côtés des serveurs non-TLS existants. Cela permet une migration progressive des clients sans interruption de service. Cependant, comme indiqué dans la section 5.1.1, il N'EST PAS RECOMMANDÉ (NOT RECOMMENDED) d'exécuter à la fois les services TLS et non-TLS sur le même hôte.

Migration par phases (Phased Migration): Une approche recommandée comprend:

  1. Phase d'évaluation (Assessment Phase): Identifier tous les clients et serveurs TACACS+ dans l'environnement
  2. Phase pilote (Pilot Phase): Déployer des serveurs TACACS+ TLS sur le port 300 dans un environnement de test
  3. Déploiement initial (Initial Deployment): Configurer un sous-ensemble de clients pour utiliser les nouveaux serveurs TLS
  4. Déploiement progressif (Gradual Rollout): Migrer progressivement des clients supplémentaires
  5. Période de surveillance (Monitoring Period): Assurer un fonctionnement stable avant de continuer
  6. Achèvement (Completion): Mettre hors service l'infrastructure non-TLS une fois tous les clients migrés

Pendant la migration, les clients TACACS+ NE DOIVENT PAS (MUST NOT) être configurés pour revenir aux connexions non-TLS si une connexion TLS échoue (section 5.1.1). Cette interdiction est essentielle pour empêcher les attaques de rétrogradation.

Les opérateurs devraient maintenir des journaux détaillés pendant la migration pour identifier les clients qui tentent encore des connexions non-TLS.

6.2. Maintenance des clients TACACS+ non-TLS (Maintaining Non-TLS TACACS+ Clients)​

Certains dispositifs hérités peuvent ne pas prendre en charge TLS et ne peuvent pas être mis à niveau. Pour ces dispositifs, les opérateurs ont plusieurs options:

  1. Infrastructure non-TLS séparée (Separate Non-TLS Infrastructure): Déployer des serveurs TACACS+ non-TLS dédiés sur des hôtes séparés (RECOMMANDÉ). Ces serveurs devraient être isolés dans un segment réseau plus restreint si possible.

  2. Actualisation matérielle progressive (Gradual Hardware Refresh): Planifier de remplacer ou de mettre à niveau les dispositifs hérités dans le cadre des cycles de renouvellement normaux.

  3. Contrôles compensatoires (Compensating Controls): Si les dispositifs hérités doivent rester, implémenter des contrôles de sécurité supplémentaires au niveau du réseau tels que des VLAN dédiés, une surveillance améliorée ou des tunnels chiffrés au niveau de la couche réseau.

Les serveurs TACACS+ non-TLS DEVRAIENT (SHOULD) être clairement documentés et surveillés. Les organisations devraient avoir une date cible pour la migration TLS complète.

6.3. Modèle YANG pour les clients TACACS+ (YANG Model for TACACS+ Clients)​

Un modèle de données YANG pour configurer les clients TACACS+, y compris les paramètres spécifiques à TLS, serait bénéfique pour l'automatisation du réseau et la gestion cohérente de la configuration sur des dispositifs réseau hétérogènes.

Un tel modèle pourrait inclure:

  • Adresses de serveur et numéros de port
  • Paramètres de configuration TLS (chemins de certificats, suites de chiffrement, etc.)
  • Comportement de repli et paramètres de délai d'attente
  • Priorités d'authentification

Le développement d'un modèle YANG standardisé est en dehors de la portée de ce document mais est encouragé en tant que travail futur. Les organisations implémentant TACACS+ sur TLS dans des systèmes de gestion basés sur YANG devraient envisager de développer des modèles neutres par rapport aux fournisseurs.

7. Considérations IANA (IANA Considerations)

L'IANA a attribué le numéro de port TCP 300 avec le nom de service "tacacss" pour TACACS+ sur TLS:

Service Name: tacacss
Transport Protocol: TCP
Port Number: 300
Description: TACACS+ over TLS
Reference: RFC 9887

8. Remerciements (Acknowledgments)

Les auteurs aimeraient reconnaître les contributions et les commentaires des participants du groupe de travail sur les opérations et la gestion de l'IETF (OPSAWG). Merci tout particulièrement à ceux qui ont fourni des contributions précieuses au cours du développement de cette spécification, y compris des examens, des suggestions et une expérience d'implémentation qui ont aidé à façonner ce document.

Le travail visant à améliorer la sécurité de TACACS+ grâce à TLS a été motivé par le besoin de la communauté opérationnelle d'une meilleure protection du trafic d'administration des dispositifs. Les auteurs apprécient l'effort de collaboration qui a rendu cette spécification possible.

9. Références (References)

9.1. Références normatives (Normative References)​

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.

    • https://www.rfc-editor.org/info/rfc2119

  • [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.

    • https://www.rfc-editor.org/info/rfc8174

  • [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018.

    • https://www.rfc-editor.org/info/rfc8446

  • [RFC8907] Dahm, T., Ota, A., Medway Gash, D., and L. Grant, "The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol", RFC 8907, DOI 10.17487/RFC8907, September 2020.

    • https://www.rfc-editor.org/info/rfc8907

  • [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008.

    • https://www.rfc-editor.org/info/rfc5280

  • [RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, November 2023.

    • https://www.rfc-editor.org/info/rfc9525

  • [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011.

    • https://www.rfc-editor.org/info/rfc6066

9.2. Références informatives (Informative References)​

  • [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011.

    • https://www.rfc-editor.org/info/rfc6151

  • [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014.

    • https://www.rfc-editor.org/info/rfc7250

  • [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security (TLS) Cached Information Extension", RFC 7924, DOI 10.17487/RFC7924, July 2016.

    • https://www.rfc-editor.org/info/rfc7924

  • [RFC9257] Housley, R., "Guidance for External Pre-Shared Key (PSK) Usage in TLS", RFC 9257, DOI 10.17487/RFC9257, July 2022.

    • https://www.rfc-editor.org/info/rfc9257

  • [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015.

    • https://www.rfc-editor.org/info/rfc7525

  • [FIPS-140-3] National Institute of Standards and Technology, "Security Requirements for Cryptographic Modules", FIPS PUB 140-3, March 2019.

    • https://csrc.nist.gov/publications/detail/fips/140/3/final

  • [REQ-TLS13] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1.1", RFC 8996, DOI 10.17487/RFC8996, March 2021.

    • https://www.rfc-editor.org/info/rfc8996

Adresses des auteurs (Authors' Addresses)​

Thorsten Dahm
Email: [email protected]

John Heasley
NTT
Email: [email protected]

Douglas C. Medway Gash
Cisco Systems, Inc.
Email: [email protected]

Andrej Ota
Google Inc.
Email: [email protected]

Dernière mise à jour le