RFC 9887 - Sintesi tecnica (versione italiana)
Documento: Terminal Access Controller Access-Control System Plus (TACACS+) su TLS 1.3
Numero RFC: 9887
Data di pubblicazione: dicembre 2025
Stato: PROPOSED STANDARD
Aggiorna: RFC 8907
Scheda di riferimento rapido
Requisiti critici (MUST)
| Requisito | Specifica | Sezione |
|---|---|---|
| Versione TLS | TLS 1.3 minimo | 3.2 |
| Numero di porta | TCP 300 per TLS | 3.1, 7 |
| Authentication | Mutua (client + server) | 3.1 |
| Validazione certificati | Percorso completo + revoca | 3.4.1 |
| Offuscamento | NON DEVE essere usato con TLS | 4 |
| Flag non crittografato | DEVE essere impostato a 1 | 4 |
| Dati 0-RTT | NON DEVE inviare | 5.1.2 |
| Fallback | NON DEVE verso non-TLS | 5.1.1 |
Metodi di Authentication supportati
-
Basato su certificato (OBBLIGATORIO)
- Certificati X.509 con validazione della catena completa
- Controllo della revoca richiesto
- DNS-ID, IP-ID o SRV-ID per l'identità del server
- Supporto dell'estensione SNI richiesto
-
Pre-Shared Keys (PSK) (OPZIONALE)
- PSK esterne (non PSK di ripresa)
- Lunghezza minima 16 ottetti
- DEVONO differire dai segreti condivisi per l'offuscamento
-
Raw Public Keys (RPK) (OPZIONALE)
- Fuori ambito per questo documento
- Vedere RFC 7250 per i dettagli
Assegnazione porte
| Servizio | Porta | Protocollo | Uso |
|---|---|---|---|
| TACACS+ (legacy) | 49 | TCP | Connessioni non-TLS |
| TACACS+ su TLS | 300 | TCP | Connessioni TLS 1.3+ |
Registrazione IANA: nome servizio "tacacss" sulla porta 300/TCP
Requisiti di configurazione TLS
Cipher suite obbligatorie
- Suite obbligatorie TLS 1.3 (RFC 8446 Sezione 9.1)
- Dovrebbero essere configurabili dagli operatori
Requisiti sui certificati
- Validazione del percorso: RFC 5280 Sezione 6
- Validazione dell'identità: RFC 9525
- Revoca: deve essere verificata all'avvio e alla ripresa
- SNI: deve essere supportato (RFC 6066 Sezione 3)
Funzionalità vietate
- ❌ Versioni TLS < 1.3
- ❌ Dati anticipati 0-RTT
- ❌ Upgrade da non-TLS
- ❌ Offuscamento basato su MD5
- ❌ Fallback a non-TLS
Ciclo di vita della connessione
Client Server
| |
|--- Connessione TCP alla porta 300 ----->|
| |
|<-- Handshake TLS 1.3 (auth mutua) ------>|
| |
|--- Dati TACACS+ (dati applicativi TLS) ->|
|<-- Risposta TACACS+ ---------------------|
| |
|--- Chiusura (dopo sessione o timeout) ->|
Modalità di connessione
-
Single Connection Mode (RFC 8907 Sezione 4.3)
- Più sessioni TACACS+ su una connessione TLS
- Soggetto a timeout per inattività
- La connessione può persistere brevemente
-
Non-Single Connection Mode
- Una sessione TACACS+ per connessione TLS
- TCP chiuso al termine della sessione
Ripresa TLS
- Durata del ticket: dovrebbe essere configurabile (anche 0 secondi)
- Uso singolo: ogni ticket per una sola ripresa
- Controllo revoche: richiesto durante il periodo di ripresa
- Comportamento del server: dovrebbe consentire se il ticket è valido e non usato
Sintesi delle considerazioni di sicurezza
Modello di minaccia affrontato
| Minaccia | Mitigazione |
|---|---|
| Intercettazione | Crittografia TLS 1.3 |
| Man-in-the-middle | Authentication mutua |
| Attacchi di replay | Nessun 0-RTT, meccanismi con nonce |
| Attacchi di downgrade | Porte separate, nessun fallback |
| Crittografia debole | MD5 obsoleto, solo TLS 1.3 |
Sicurezza in deployment
-
Separazione TLS e non-TLS
- RACCOMANDATO: host fisici separati
- DEVE: numeri di porta separati
- Previene esposizioni per errata configurazione
-
Gestione certificati
- Seguire BCP 195 (RFC 7525)
- Certificati wildcard: limitati a sottodominio dedicato
- Raggiungibilità della CA: pianificare per isolamento di rete
-
Chiarezza di configurazione
- Indicatori espliciti modalità TLS/non-TLS
- Avvisi di validazione per disallineamenti di porta
- Sezioni di configurazione separate
Strategia di migrazione (5 fasi)
Fase 1: Valutazione
- Inventariare tutti i client e server TACACS+
- Identificare dispositivi abilitati a TLS vs legacy
- Pianificare modifiche alla topologia di rete
Fase 2: Pilota
- Distribuire server TLS sulla porta 300 in ambiente di test
- Configurare client di test
- Validare l'infrastruttura a certificati
Fase 3: Distribuzione iniziale
- Migrare un sottoinsieme di client di produzione
- Monitorare per problemi
- Mantenere infrastruttura non-TLS in parallelo
Fase 4: Rollout graduale
- Migrare incrementalmente i client rimanenti
- Documentare eventuali eccezioni per dispositivi legacy
- Implementare controlli compensativi per non-TLS
Fase 5: Completamento
- Dismettere l'infrastruttura non-TLS
- Audit di sicurezza finale
- Aggiornare la documentazione
Regola critica: i client NON DEVONO fare fallback a non-TLS se TLS fallisce
Checklist di implementazione
Implementazione server
- Supporto TLS 1.3 (minimo)
- Ascolto sulla porta 300 (o alternativa configurata)
- Authentication mutua basata su certificato
- Validazione percorso certificati (RFC 5280)
- Controllo revoche
- Supporto estensione SNI
- Rifiutare pacchetti senza TAC_PLUS_UNENCRYPTED_FLAG
- Rifiutare dati 0-RTT
- Supporto ripresa TLS
- Durata ticket configurabile
- Opzionale: Authentication PSK
- Opzionale: Raw Public Keys
Implementazione client
- Supporto TLS 1.3 (minimo)
- Connessione alla porta 300 (o configurata)
- Negoziazione TLS immediata (nessun upgrade)
- Validazione certificati
- Estensione SNI nel ClientHello
- Impostare TAC_PLUS_UNENCRYPTED_FLAG = 1
- Nessuna trasmissione dati 0-RTT
- Nessun fallback a non-TLS
- Supporto ripresa TLS
- Opzionale: Authentication PSK
- Opzionale: Raw Public Keys
Note sull'implementazione di riferimento
Validazione identità del certificato
Tipi di identificatore accettabili:
- DNS-ID: tacacs.example.com
- IP-ID: 192.0.2.1 o 2001:db8::1
- SRV-ID: _tacacs._tcp.example.com
NON accettabili:
- URI-ID (non usato per TACACS+)
Certificati wildcard
✅ BUONO: *.tacacs.example.com (sottodominio dedicato)
❌ SCARSO: *.example.com (troppo ampio)
Formato identità PSK
- Lunghezza minima: 16 ottetti
- Seguire RFC 9257 Sezione 6.1
- Deve differire dai segreti di offuscamento
Buone pratiche operative
-
Monitoraggio
- Registrare tutti i fallimenti di handshake TLS
- Allertare su tentativi di connessione non-TLS alla porta 300
- Tracciare le date di scadenza dei certificati
-
Ciclo di vita dei certificati
- Automatizzare il rinnovo (es. protocollo ACME)
- Mantenere localmente le catene di certificati
- Pianificare per interruzioni della CA
-
Test
- Audit periodici della configurazione TLS
- Test di compatibilità delle cipher suite
- Validazione scenari di failover
-
Documentazione
- Mantenere inventario server TLS vs non-TLS
- Documentare la timeline di migrazione
- Registrare gli anchor di fiducia dei certificati
Requisiti di conformità
FIPS 140-3
- TLS 1.3 con cipher suite approvate
- Offuscamento MD5 obsoleto (non conforme)
- Authentication basata su certificato raccomandata
Standard di settore
- PCI DSS: crittografia forte richiesta
- NIST SP 800-52: linee guida TLS
- BCP 195: best practice TLS
Errori comuni da evitare
- ❌ Disallineamento porta: client TLS che si connette alla porta 49
- ❌ Logica di fallback: tentativo non-TLS dopo fallimento TLS
- ❌ Segreti misti: usare le stesse chiavi per offuscamento e PSK
- ❌ 0-RTT abilitato: invio di dati anticipati
- ❌ Validazione certificati disabilitata: accettare certificati non validi
- ❌ Stesso host: eseguire TLS e non-TLS sullo stesso server
- ❌ Uso improprio wildcard: usare *.example.com per tutti i servizi
- ❌ Nessun controllo revoche: saltare validazione CRL/OCSP
Considerazioni sulle prestazioni
Overhead handshake TLS
- Handshake completo: ~2 RTT (TLS 1.3)
- Ripresa: ~1 RTT
- Mitigazione: usare la ripresa per connessioni ripetute
Persistenza connessione
- Single Connection Mode riduce la frequenza degli handshake
- Bilanciare riuso connessione e impostazioni di timeout
- Timeout tipico: 60-300 secondi
Validazione certificati
- Memorizzare in cache i certificati validati
- Usare OCSP stapling per ridurre la latenza
- Considerare TLS Cached Information Extension (RFC 7924)
Guida al troubleshooting
| Sintomo | Possibile causa | Soluzione |
|---|---|---|
| Connessione rifiutata | Porta errata | Verificare client configurato per porta 300 |
| Fallimento handshake | Versione TLS non allineata | Garantire supporto TLS 1.3 |
| Errore certificato | Catena certificati non valida | Verificare fiducia CA e validità certificato |
| Authentication fallita | Problema auth mutua | Controllare certificati client e server |
| Errore TAC_PLUS_UNENCRYPTED_FLAG | Flag non impostato | Garantire che il client imposti il flag a 1 |
| Ripresa rifiutata | Ticket scaduto/usato | Normale; procederà handshake completo |
Considerazioni future
Modello dati YANG
- Serve un modello di configurazione standardizzato
- Beneficierebbe automazione e coerenza
- Dovrebbe includere parametri specifici TLS
Estensioni del protocollo
- Questo documento si concentra su TLS 1.3
- Si prevede che versioni TLS future funzionino
- Monitorare TLS WG IETF per aggiornamenti
Deployment IPv6
- Nessuna modifica alle raccomandazioni IPv6
- TLS funziona allo stesso modo su IPv4 e IPv6
- Usare IP-ID per identità certificato basata su IP
Albero decisionale rapido
Serve sicurezza TACACS+?
├─ SÌ → Usare TLS (questa RFC)
│ ├─ Dispositivi moderni → Authentication basata su certificato
│ ├─ Dispositivi vincolati → Valutare PSK
│ └─ Dispositivi legacy → Infrastruttura non-TLS separata
│
└─ NO → Valutare se TACACS+ è appropriato
└─ Ambienti ad alta sicurezza richiedono TLS
RFC correlate
- RFC 8907: Protocollo TACACS+ di base (aggiornato da questa RFC)
- RFC 8446: TLS 1.3 (strato di trasporto)
- RFC 5280: X.509 PKI (certificati)
- RFC 9525: Service Identity in TLS (validazione identità)
- RFC 9257: Linee guida PSK esterne
- RFC 7525 (BCP 195): Best practice TLS
Stato del documento
- Standards Track: Sì
- Implementazione richiesta: Per nuovi deployment
- Compatibilità all'indietro: Operazione in parallelo durante la migrazione
- Rende obsoleto: Solo il meccanismo di offuscamento MD5
- Aggiorna: RFC 8907 (aggiunge profilo TLS)
Ultimo aggiornamento: 26 dicembre 2025
Versione documento: 1.0 (versione italiana completa)
Mantenuto da: RFC Translation Project