Aller au contenu principal

RFC 9887 - Résumé technique (version française)

Document : Terminal Access Controller Access-Control System Plus (TACACS+) sur TLS 1.3
Numéro RFC : 9887
Date de publication : décembre 2025
Statut : NORME PROPOSÉE (PROPOSED STANDARD)
Met à jour : RFC 8907

Fiche de référence rapide​

Exigences critiques (MUST)​

ExigenceSpécificationSection
Version TLSTLS 1.3 minimum3.2
Numéro de portTCP 300 pour TLS3.1, 7
AuthenticationMutuelle (client + serveur)3.1
Validation des certificatsChaîne complète + révocation3.4.1
ObfuscationNE DOIT PAS être utilisée avec TLS4
Indicateur non chiffréDOIT être fixé à 14
Données 0-RTTNE DOIT PAS être envoyées5.1.2
Repli (fallback)NE DOIT PAS vers du non-TLS5.1.1

Méthodes d’Authentication prises en charge​

  1. Par certificat (Certificate-Based) (OBLIGATOIRE)

    • Certificats X.509 avec validation de chaîne complète
    • Vérification de révocation requise
    • DNS-ID, IP-ID ou SRV-ID pour l’identité du serveur
    • Prise en charge de l’extension SNI requise

  2. Clés pré-partagées (Pre-Shared Keys, PSK) (OPTIONNEL)

    • PSK externes (pas des PSK de reprise de session)
    • Longueur minimale 16 octets
    • DOIVENT différer des secrets partagés d’obfuscation

  3. Clés publiques brutes (Raw Public Keys, RPK) (OPTIONNEL)

    • Hors du périmètre de ce document
    • Voir la RFC 7250 pour les détails

Attribution des ports​

ServicePortProtocoleUsage
TACACS+ (héritage)49TCPConnexions sans TLS
TACACS+ sur TLS300TCPConnexions TLS 1.3 et ultérieures

Enregistrement IANA : nom de service « tacacss » sur le port 300/TCP

Exigences de configuration TLS​

Suites cryptographiques obligatoires​

  • Suites obligatoires de TLS 1.3 (RFC 8446, section 9.1)
  • Devraient être configurables par les opérateurs

Exigences relatives aux certificats​

  • Validation de chemin : RFC 5280, section 6
  • Validation d’identité : RFC 9525
  • Révocation : doit être vérifiée lors de l’établissement initial et de la reprise
  • SNI : doit être pris en charge (RFC 6066, section 3)

Fonctionnalités interdites​

  • Versions TLS < 1.3
  • Données anticipées 0-RTT
  • Passage depuis une connexion non-TLS
  • Obfuscation basée sur MD5
  • Repli vers du non-TLS

Cycle de vie de la connexion​

Client                                    Serveur
  |                                          |
  |--- Connexion TCP vers le port 300 ----->|
  |                                          |
  |<-- Poignée de main TLS 1.3 (auth mutuelle) -->|
  |                                          |
  |--- Données TACACS+ (données applicatives TLS) ->|
  |<-- Réponse TACACS+ ----------------------|
  |                                          |
  |--- Fermeture (après session ou délai) -->|

Modes de connexion​

  1. Mode connexion unique (Single Connection Mode) (RFC 8907, section 4.3)

    • Plusieurs sessions TACACS+ sur une connexion TLS
    • Soumis à un délai d’inactivité
    • La connexion peut persister brièvement

  2. Mode sans connexion unique (Non-Single Connection Mode)

    • Une session TACACS+ par connexion TLS
    • TCP fermé après fin de session

Reprise TLS​

  • Durée de vie du ticket : devrait être configurable (y compris 0 seconde)
  • Usage unique : chaque ticket pour une seule reprise
  • Vérification de révocation : requise pendant la période de reprise
  • Comportement du serveur : devrait autoriser si le ticket est valide et inutilisé

Synthèse des considérations de sécurité​

Modèle de menace pris en charge​

MenaceAtténuation
Écoute clandestineChiffrement TLS 1.3
Homme du milieu (Man-in-the-Middle)Authentication mutuelle
Attaques par rejeuPas de 0-RTT, mécanismes de nonce
Attaques par rétrogradationPorts distincts, pas de repli
Cryptographie faibleMD5 obsolète, TLS 1.3 uniquement

Sécurité du déploiement​

  1. Séparation TLS et non-TLS

    • RECOMMANDÉ : hôtes physiques distincts
    • DOIT : numéros de port distincts
    • Limite l’exposition due à une mauvaise configuration

  2. Gestion des certificats

    • Suivre la BCP 195 (RFC 7525)
    • Certificats génériques (wildcard) : limités à un sous-domaine dédié
    • Atteignabilité de l’AC : prévoir l’isolement réseau

  3. Clarté de la configuration

    • Indicateurs explicites de mode TLS / non-TLS
    • Avertissements de validation en cas d’incohérence de port
    • Sections de configuration distinctes

Stratégie de migration (5 phases)​

Phase 1 : Évaluation​

  • Inventorier tous les clients et serveurs TACACS+
  • Identifier les équipements compatibles TLS et hérités
  • Planifier les changements de topologie réseau

Phase 2 : Pilote​

  • Déployer des serveurs TLS sur le port 300 en environnement de test
  • Configurer les clients de test
  • Valider l’infrastructure de certificats

Phase 3 : Déploiement initial​

  • Migrer un sous-ensemble de clients de production
  • Surveiller les incidents
  • Maintenir une infrastructure non-TLS en parallèle

Phase 4 : Déploiement progressif​

  • Migrer par étapes les clients restants
  • Documenter les exceptions pour équipements hérités
  • Mettre en œuvre des mesures compensatoires pour le non-TLS

Phase 5 : Achèvement​

  • Désactiver l’infrastructure non-TLS
  • Audit de sécurité final
  • Mettre à jour la documentation

Règle critique : les clients NE DOIVENT PAS se replier sur du non-TLS en cas d’échec TLS

Liste de contrôle d’implémentation​

Implémentation serveur​

  • Prise en charge de TLS 1.3 (minimum)
  • Écoute sur le port 300 (ou alternative configurée)
  • Authentication mutuelle par certificat
  • Validation du chemin de certificat (RFC 5280)
  • Vérification de révocation
  • Prise en charge de l’extension SNI
  • Rejet des paquets sans TAC_PLUS_UNENCRYPTED_FLAG
  • Rejet des données 0-RTT
  • Prise en charge de la reprise TLS
  • Durée de vie du ticket configurable
  • Optionnel : Authentication par PSK
  • Optionnel : Raw Public Keys

Implémentation client​

  • Prise en charge de TLS 1.3 (minimum)
  • Connexion au port 300 (ou configuré)
  • Négociation TLS immédiate (sans upgrade)
  • Validation des certificats
  • Extension SNI dans ClientHello
  • Définir TAC_PLUS_UNENCRYPTED_FLAG = 1
  • Aucune transmission de données 0-RTT
  • Pas de repli vers du non-TLS
  • Prise en charge de la reprise TLS
  • Optionnel : Authentication par PSK
  • Optionnel : Raw Public Keys

Notes pour une implémentation de référence​

Validation de l’identité par certificat​

Types d’identifiants acceptables :
- DNS-ID : tacacs.example.com
- IP-ID : 192.0.2.1 ou 2001:db8::1
- SRV-ID : _tacacs._tcp.example.com

NON acceptables :
- URI-ID (non utilisé pour TACACS+)

Certificats génériques (wildcard)​

✅ BON : *.tacacs.example.com (sous-domaine dédié)
❌ MAUVAIS : *.example.com (trop large)

Format d’identité PSK​

- Longueur minimale : 16 octets
- Suivre la RFC 9257, section 6.1
- Doit différer des secrets d’obfuscation

Bonnes pratiques opérationnelles​

  1. Supervision

    • Journaliser tous les échecs de poignée de main TLS
    • Alerter sur les tentatives de connexion non-TLS vers le port 300
    • Suivre les dates d’expiration des certificats

  2. Cycle de vie des certificats

    • Automatiser le renouvellement (par ex. protocole ACME)
    • Conserver les chaînes de certificats localement
    • Prévoir les pannes d’AC

  3. Tests

    • Audits réguliers de la configuration TLS
    • Tests de compatibilité des suites cryptographiques
    • Validation des scénarios de basculement

  4. Documentation

    • Tenir un inventaire des serveurs TLS vs non-TLS
    • Documenter le calendrier de migration
    • Enregistrer les ancres de confiance des certificats

Exigences de conformité​

FIPS 140-3​

  • TLS 1.3 avec suites cryptographiques approuvées
  • Obfuscation MD5 obsolète (non conforme)
  • Authentication par certificat recommandée

Normes du secteur​

  • PCI DSS : cryptographie forte requise
  • NIST SP 800-52 : lignes directrices TLS
  • BCP 195 : bonnes pratiques TLS

Pièges courants à éviter​

  1. ❌ Incohérence de port : client TLS se connectant au port 49
  2. ❌ Logique de repli : tentative de non-TLS après échec TLS
  3. ❌ Secrets mélangés : mêmes clés pour obfuscation et PSK
  4. ❌ 0-RTT activé : envoi de données anticipées
  5. ❌ Validation des certificats désactivée : acceptation de certificats invalides
  6. ❌ Même hôte : TLS et non-TLS sur le même serveur
  7. ❌ Abus de wildcard : utilisation de *.example.com pour tous les services
  8. ❌ Absence de vérification de révocation : omission de la validation CRL/OCSP

Considérations de performance​

Surcharge de la poignée de main TLS​

  • Poignée de main complète : ~2 aller-retour (TLS 1.3)
  • Reprise : ~1 aller-retour
  • Atténuation : utiliser la reprise pour les connexions répétées

Persistance des connexions​

  • Le mode connexion unique réduit la fréquence des poignées de main
  • Équilibre entre réutilisation des connexions et paramètres de délai
  • Délai typique : 60 à 300 secondes

Validation des certificats​

  • Mettre en cache les certificats validés
  • Utiliser l’OCSP stapling pour réduire la latence
  • Envisager l’extension TLS Cached Information (RFC 7924)

Guide de dépannage​

SymptômeCause possibleSolution
Connexion refuséeMauvais portVérifier que le client est configuré pour le port 300
Échec de poignée de mainIncompatibilité de version TLSGarantir la prise en charge de TLS 1.3
Erreur de certificatChaîne de certificats invalideVérifier la confiance en l’AC et la validité du certificat
Authentication échouéeProblème d’auth mutuelleVérifier les certificats client et serveur
Erreur TAC_PLUS_UNENCRYPTED_FLAGIndicateur non définiS’assurer que le client fixe l’indicateur à 1
Reprise refuséeTicket expiré / déjà utiliséNormal ; une poignée de main complète suivra

Évolutions futures​

Modèle de données YANG​

  • Besoin d’un modèle de configuration normalisé
  • Bénéficierait de l’automatisation et de la cohérence
  • Devrait inclure des paramètres spécifiques à TLS

Extensions de protocole​

  • Ce document se concentre sur TLS 1.3
  • Les versions TLS ultérieures devraient fonctionner
  • Suivre le groupe de travail TLS de l’IETF pour les mises à jour

Déploiement IPv6​

  • Aucun changement aux recommandations IPv6
  • TLS fonctionne de la même manière sur IPv4 et IPv6
  • Utiliser IP-ID pour l’identité par certificat basée sur l’IP

Arbre de décision rapide​

Avez-vous besoin de la sécurité TACACS+ ?
├─ OUI → Utiliser TLS (cette RFC)
│   ├─ Équipements récents → Authentication par certificat
│   ├─ Équipements contraints → Envisager PSK
│   └─ Équipements hérités → Infrastructure non-TLS séparée
│
└─ NON → Évaluer si TACACS+ est adapté
    └─ Les environnements à haute exigence de sécurité exigent TLS

RFC associées​

  • RFC 8907 : protocole TACACS+ de base (mise à jour par cette RFC)
  • RFC 8446 : TLS 1.3 (couche transport)
  • RFC 5280 : PKI X.509 (certificats)
  • RFC 9525 : identité de service dans TLS (validation d’identité)
  • RFC 9257 : lignes directrices sur les PSK externes
  • RFC 7525 (BCP 195) : bonnes pratiques TLS

Statut du document​

  • Piste des normes (Standards Track) : oui
  • Implémentation requise : pour les nouveaux déploiements
  • Rétrocompatibilité : fonctionnement en parallèle pendant la migration
  • Rend obsolète : uniquement le mécanisme d’obfuscation MD5
  • Met à jour : RFC 8907 (ajoute le profil TLS)

Dernière mise à jour : 26 décembre 2025
Version du document : 1.0 (version française complète)
Maintenu par : Projet de traduction RFC