Passa al contenuto principale

4. Obsolescenza dell'offuscamento TACACS+ (Obsolescence of TACACS+ Obfuscation)

Il meccanismo di offuscamento documentato nella sezione 4.5 di [RFC8907] è debole.

L'introduzione dell'autenticazione e della crittografia TLS in TACACS+ sostituisce questo meccanismo precedente, quindi l'offuscamento è qui dichiarato obsoleto. Questa sezione descrive come i client e i server TACACS+ DEVONO operare riguardo al meccanismo di offuscamento.

I peer NON DEVONO (MUST NOT) utilizzare l'offuscamento con TLS.

Un client TACACS+ che avvia una connessione TACACS+ TLS DEVE (MUST) impostare il bit TAC_PLUS_UNENCRYPTED_FLAG, affermando così che l'offuscamento non viene utilizzato per la sessione. Tutti i pacchetti successivi DEVONO (MUST) avere il bit TAC_PLUS_UNENCRYPTED_FLAG impostato su 1.

Un server TACACS+ TLS che riceve un pacchetto con il bit TAC_PLUS_UNENCRYPTED_FLAG non impostato su 1 su una connessione TLS DEVE (MUST) restituire un errore di TAC_PLUS_AUTHEN_STATUS_ERROR, TAC_PLUS_AUTHOR_STATUS_ERROR o TAC_PLUS_ACCT_STATUS_ERROR come appropriato per il tipo di messaggio TACACS+, con il bit TAC_PLUS_UNENCRYPTED_FLAG impostato su 1, e terminare la sessione.

Un client TACACS+ che riceve un pacchetto con il bit TAC_PLUS_UNENCRYPTED_FLAG non impostato su 1 DEVE (MUST) terminare la sessione e DOVREBBE (SHOULD) registrare questo errore.

5. Considerazioni sulla sicurezza (Security Considerations)

5.1. TLS​

Questo documento migliora la riservatezza, l'integrità e l'autenticazione della connessione e del traffico di rete tra i peer TACACS+ aggiungendo il supporto TLS.

La semplice aggiunta del supporto TLS al protocollo non garantisce la protezione del server e dei client TACACS+ TLS. È essenziale che gli operatori e i fornitori di apparecchiature aderiscano alle ultime best practice per garantire l'integrità dei dispositivi di rete e selezionare algoritmi di crittografia e chiavi TLS sicuri.

[BCP195] offre una guida sostanziale per l'implementazione e la distribuzione di protocolli che utilizzano TLS. Coloro che implementano e distribuiscono Secure TACACS+ devono aderire alle raccomandazioni relative a TLS 1.3 delineate in [BCP195] o nelle sue versioni successive.

5.1.1. Utilizzo di TLS (TLS Use)​

Le nuove distribuzioni di produzione TACACS+ DOVREBBERO (SHOULD) utilizzare l'autenticazione e la crittografia TLS.

I server TACACS+ TLS (come definiti nella sezione 2) NON DEVONO (MUST NOT) consentire connessioni non-TLS, a causa della minaccia di attacchi di downgrade o di configurazione errata descritta nella sezione 5.3. Invece, server TACACS+ non-TLS separati DOVREBBERO (SHOULD) essere configurati per soddisfare questi client.

NON È RACCOMANDATO (NOT RECOMMENDED) che i server TACACS+ TLS e i server TACACS+ non-TLS siano distribuiti sullo stesso host, per le ragioni discusse nella sezione 5.3. Le connessioni non-TLS sarebbero meglio servite distribuendo i server TACACS+ non-TLS richiesti su host separati.

I client TACACS+ NON DEVONO (MUST NOT) tornare a una connessione non-TLS se una connessione TLS fallisce. Questo divieto include durante la migrazione di una distribuzione (sezione 6.1).

5.1.2. TLS 0-RTT​

Le tecniche di ripresa e PSK di TLS 1.3 rendono possibile inviare dati anticipati, noti come dati 0-RTT, dati inviati prima che l'handshake TLS sia completato. La ripetizione di questi dati è un rischio. Data la sensibilità dei dati TACACS+, i client NON DEVONO (MUST NOT) inviare dati fino a quando l'handshake TLS completo non è completato; cioè, i client NON DEVONO (MUST NOT) inviare dati 0-RTT e i server TACACS+ TLS DEVONO (MUST) disconnettere bruscamente i client che lo fanno.

I client e i server TACACS+ TLS NON DEVONO (MUST NOT) includere l'estensione early_data. Vedere le sezioni 2.3 e 4.2.10 di [RFC8446] per le preoccupazioni sulla sicurezza.

5.1.3. Opzioni TLS (TLS Options)​

Le raccomandazioni in [BCP195] DEVONO (MUST) essere seguite per determinare quali versioni e algoritmi TLS dovrebbero essere supportati, deprecati, obsoleti o abbandonati.

Inoltre, la sezione 9 di [RFC8446] prescrive le opzioni obbligatorie supportate.

5.1.4. Autorità di certificazione (CA) non raggiungibile (Unreachable Certificate Authority)​

Gli operatori dovrebbero essere consapevoli del potenziale isolamento del server e/o del client TACACS+ TLS dalla CA del loro peer a causa di guasti di rete. L'isolamento dalla CA di un certificato a chiave pubblica causerà il fallimento della verifica del certificato e quindi il fallimento dell'autenticazione TLS del peer. L'approccio menzionato nella sezione 3.4.1 può aiutare ad affrontare questo problema e dovrebbe essere considerato.

5.1.5. Indicatore del nome del server TLS (SNI) (TLS Server Name Indicator)​

Gli operatori dovrebbero essere consapevoli che l'estensione TLS SNI fa parte del client hello TLS, che viene inviato in chiaro. È quindi soggetto a intercettazioni. Vedere anche la sezione 11.1 di [RFC6066].

5.1.6. Caratteri jolly dell'identità del server (Server Identity Wildcards)​

L'uso di caratteri jolly nelle identità del server TLS crea un singolo punto di guasto: una chiave privata compromessa di un certificato con carattere jolly impatta tutti i server che lo utilizzano. Il loro uso DEVE (MUST) seguire le raccomandazioni della sezione 7.1 di [RFC9525]. Gli operatori DEVONO (MUST) garantire che il carattere jolly sia limitato a un sottodominio dedicato esclusivamente ai server TACACS+ TLS.

5.2. Configurazione TACACS+ (TACACS+ Configuration)​

Gli implementatori devono garantire che lo schema di configurazione introdotto per abilitare TLS sia semplice e non lasci spazio all'ambiguità riguardo all'uso di TLS o non-TLS tra il client TACACS+ e il server TACACS+.

Questo documento raccomanda l'uso di un numero di porta separato su cui i server TACACS+ TLS ascolteranno. Quando le distribuzioni non hanno sovrascritto esplicitamente i valori predefiniti, le implementazioni dei client TACACS+ DEVONO (MUST) utilizzare i valori di porta corretti:

  • Porta 49: per la connessione TACACS+ non-TLS
  • Porta 300: per la connessione TACACS+ TLS

Gli implementatori possono offrire un'opzione singola per i client e i server TACACS+ per disabilitare tutte le operazioni TACACS+ non-TLS. Quando abilitata su un server TACACS+, non risponderà ad alcuna richiesta da connessioni di client TACACS+ non-TLS. Quando abilitata su un client TACACS+, non stabilirà alcuna connessione di server TACACS+ non-TLS.

Una configurazione errata comune consiste nell'abilitare TLS sul server ma configurare erroneamente il client per utilizzare la porta non-TLS, o viceversa. Per prevenire ciò, le pratiche di configurazione chiare DOVREBBERO (SHOULD) includere:

  • Indicatori di modalità TLS/non-TLS espliciti nei file di configurazione
  • Avvisi di convalida quando i numeri di porta non corrispondono alla modalità configurata
  • Sezioni di configurazione separate per i server TLS e non-TLS

5.3. Numero di porta TCP/IP ben noto (Well-Known TCP/IP Port Number)​

Un nuovo numero di porta è considerato appropriato (piuttosto che un meccanismo che negozia un aggiornamento da una connessione TACACS+ non-TLS iniziale) perché consente:

  • facilità di blocco delle connessioni non offuscate o offuscate tramite il numero di porta TCP/IP,
  • i sistemi di rilevamento delle intrusioni (IDS) passivi che monitorano le non offuscate non sono influenzati dall'introduzione di TLS,
  • prevenzione degli attacchi on-path che possono interferire con l'aggiornamento, e
  • prevenzione dell'esposizione accidentale di informazioni sensibili a causa di configurazione errata.

6. Considerazioni operative (Operational Considerations)

6.1. Migrazione (Migration)​

Per facilitare una transizione fluida dalle distribuzioni TACACS+ legacy a TACACS+ protetto da TLS, le organizzazioni devono pianificare attentamente la loro migrazione. Le strategie di migrazione più comuni sono:

Operazione parallela (Parallel Operation): Gli operatori possono distribuire nuovi server TACACS+ TLS insieme ai server non-TLS esistenti. Ciò consente la migrazione graduale dei client senza interruzione del servizio. Tuttavia, come notato nella sezione 5.1.1, NON È RACCOMANDATO (NOT RECOMMENDED) eseguire entrambi i servizi TLS e non-TLS sullo stesso host.

Migrazione a fasi (Phased Migration): Un approccio raccomandato include:

  1. Fase di valutazione (Assessment Phase): Identificare tutti i client e i server TACACS+ nell'ambiente
  2. Fase pilota (Pilot Phase): Distribuire i server TACACS+ TLS sulla porta 300 in un ambiente di test
  3. Distribuzione iniziale (Initial Deployment): Configurare un sottoinsieme di client per utilizzare i nuovi server TLS
  4. Implementazione graduale (Gradual Rollout): Migrare gradualmente i client aggiuntivi
  5. Periodo di monitoraggio (Monitoring Period): Garantire un funzionamento stabile prima di procedere
  6. Completamento (Completion): Dismettere l'infrastruttura non-TLS una volta che tutti i client sono migrati

Durante la migrazione, i client TACACS+ NON DEVONO (MUST NOT) essere configurati per tornare alle connessioni non-TLS se una connessione TLS fallisce (sezione 5.1.1). Questo divieto è essenziale per prevenire gli attacchi di downgrade.

Gli operatori dovrebbero mantenere registri dettagliati durante la migrazione per identificare eventuali client che tentano ancora connessioni non-TLS.

6.2. Mantenimento dei client TACACS+ non-TLS (Maintaining Non-TLS TACACS+ Clients)​

Alcuni dispositivi legacy potrebbero non supportare TLS e non possono essere aggiornati. Per questi dispositivi, gli operatori hanno diverse opzioni:

  1. Infrastruttura non-TLS separata (Separate Non-TLS Infrastructure): Distribuire server TACACS+ non-TLS dedicati su host separati (RACCOMANDATO). Questi server dovrebbero essere isolati in un segmento di rete più ristretto, se possibile.

  2. Aggiornamento hardware graduale (Gradual Hardware Refresh): Pianificare la sostituzione o l'aggiornamento dei dispositivi legacy come parte dei normali cicli di aggiornamento.

  3. Controlli compensativi (Compensating Controls): Se i dispositivi legacy devono rimanere, implementare controlli di sicurezza aggiuntivi a livello di rete come VLAN dedicate, monitoraggio migliorato o tunnel crittografati a livello di rete.

I server TACACS+ non-TLS DOVREBBERO (SHOULD) essere chiaramente documentati e monitorati. Le organizzazioni dovrebbero avere una data obiettivo per la migrazione TLS completa.

6.3. Modello YANG per i client TACACS+ (YANG Model for TACACS+ Clients)​

Un modello di dati YANG per configurare i client TACACS+, inclusi i parametri specifici di TLS, sarebbe vantaggioso per l'automazione della rete e la gestione coerente della configurazione su dispositivi di rete eterogenei.

Un tale modello potrebbe includere:

  • Indirizzi del server e numeri di porta
  • Parametri di configurazione TLS (percorsi dei certificati, suite di cifratura, ecc.)
  • Comportamento di fallback e impostazioni di timeout
  • Priorità di autenticazione

Lo sviluppo di un modello YANG standardizzato è al di fuori dell'ambito di questo documento ma è incoraggiato come lavoro futuro. Le organizzazioni che implementano TACACS+ su TLS in sistemi di gestione basati su YANG dovrebbero considerare lo sviluppo di modelli indipendenti dal fornitore.

7. Considerazioni IANA (IANA Considerations)

IANA ha assegnato il numero di porta TCP 300 con il nome del servizio "tacacss" per TACACS+ su TLS:

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

8. Ringraziamenti (Acknowledgments)

Gli autori vorrebbero riconoscere i contributi e il feedback dei partecipanti al gruppo di lavoro IETF Operations and Management Area Working Group (OPSAWG). Ringraziamenti speciali a coloro che hanno fornito input preziosi durante lo sviluppo di questa specifica, inclusi revisioni, suggerimenti ed esperienza di implementazione che hanno contribuito a dare forma a questo documento.

Il lavoro per migliorare la sicurezza di TACACS+ attraverso TLS è stato guidato dalla necessità della comunità operativa di una migliore protezione del traffico di amministrazione dei dispositivi. Gli autori apprezzano lo sforzo collaborativo che ha reso possibile questa specifica.

9. Riferimenti (References)

9.1. Riferimenti normativi (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. Riferimenti informativi (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

Indirizzi degli autori (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]

Ultimo aggiornamento il