Passa al contenuto principale

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)​

RequisitoSpecificaSezione
Versione TLSTLS 1.3 minimo3.2
Numero di portaTCP 300 per TLS3.1, 7
AuthenticationMutua (client + server)3.1
Validazione certificatiPercorso completo + revoca3.4.1
OffuscamentoNON DEVE essere usato con TLS4
Flag non crittografatoDEVE essere impostato a 14
Dati 0-RTTNON DEVE inviare5.1.2
FallbackNON DEVE verso non-TLS5.1.1

Metodi di Authentication supportati​

  1. 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

  2. Pre-Shared Keys (PSK) (OPZIONALE)

    • PSK esterne (non PSK di ripresa)
    • Lunghezza minima 16 ottetti
    • DEVONO differire dai segreti condivisi per l'offuscamento

  3. Raw Public Keys (RPK) (OPZIONALE)

    • Fuori ambito per questo documento
    • Vedere RFC 7250 per i dettagli

Assegnazione porte​

ServizioPortaProtocolloUso
TACACS+ (legacy)49TCPConnessioni non-TLS
TACACS+ su TLS300TCPConnessioni 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​

  1. 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

  2. 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​

MinacciaMitigazione
IntercettazioneCrittografia TLS 1.3
Man-in-the-middleAuthentication mutua
Attacchi di replayNessun 0-RTT, meccanismi con nonce
Attacchi di downgradePorte separate, nessun fallback
Crittografia deboleMD5 obsoleto, solo TLS 1.3

Sicurezza in deployment​

  1. Separazione TLS e non-TLS

    • RACCOMANDATO: host fisici separati
    • DEVE: numeri di porta separati
    • Previene esposizioni per errata configurazione

  2. Gestione certificati

    • Seguire BCP 195 (RFC 7525)
    • Certificati wildcard: limitati a sottodominio dedicato
    • Raggiungibilità della CA: pianificare per isolamento di rete

  3. 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​

  1. 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

  2. Ciclo di vita dei certificati

    • Automatizzare il rinnovo (es. protocollo ACME)
    • Mantenere localmente le catene di certificati
    • Pianificare per interruzioni della CA

  3. Test

    • Audit periodici della configurazione TLS
    • Test di compatibilità delle cipher suite
    • Validazione scenari di failover

  4. 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​

  1. ❌ Disallineamento porta: client TLS che si connette alla porta 49
  2. ❌ Logica di fallback: tentativo non-TLS dopo fallimento TLS
  3. ❌ Segreti misti: usare le stesse chiavi per offuscamento e PSK
  4. ❌ 0-RTT abilitato: invio di dati anticipati
  5. ❌ Validazione certificati disabilitata: accettare certificati non validi
  6. ❌ Stesso host: eseguire TLS e non-TLS sullo stesso server
  7. ❌ Uso improprio wildcard: usare *.example.com per tutti i servizi
  8. ❌ 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​

SintomoPossibile causaSoluzione
Connessione rifiutataPorta errataVerificare client configurato per porta 300
Fallimento handshakeVersione TLS non allineataGarantire supporto TLS 1.3
Errore certificatoCatena certificati non validaVerificare fiducia CA e validità certificato
Authentication fallitaProblema auth mutuaControllare certificati client e server
Errore TAC_PLUS_UNENCRYPTED_FLAGFlag non impostatoGarantire che il client imposti il flag a 1
Ripresa rifiutataTicket scaduto/usatoNormale; 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