4. Architecture (Architettura)

4.1. Host Keys (Chiavi host)

Ogni server host DOVREBBE avere una chiave host. Gli host POSSONO avere più chiavi host utilizzando diversi algoritmi. Più host POSSONO condividere la stessa chiave host. Se un host ha chiavi, DEVE avere almeno una chiave che utilizza ogni algoritmo di chiave pubblica RICHIESTO (DSS [FIPS-186-2]).

La chiave host del server viene utilizzata durante lo scambio di chiavi per verificare che il client stia realmente comunicando con il server corretto. Perché ciò sia possibile, il client deve avere conoscenza a priori della chiave host pubblica del server.

Possono essere utilizzati due diversi modelli di fiducia:

Il client ha un database locale che associa ogni nome host (come digitato dall'utente) con la corrispondente chiave host pubblica. Questo metodo non richiede un'infrastruttura amministrata centralmente e nessuna coordinazione di terze parti. Lo svantaggio è che il database delle associazioni nome-chiave può diventare oneroso da mantenere.
L'associazione nome host-chiave è certificata da un'autorità di certificazione (CA) fidata. Il client conosce solo la chiave radice della CA e può verificare la validità di tutte le chiavi host certificate dalle CA accettate.

La seconda alternativa facilita il problema della manutenzione, poiché idealmente solo una singola chiave CA deve essere archiviata in modo sicuro sul client. D'altra parte, ogni chiave host deve essere opportunamente certificata da un'autorità centrale prima che l'autorizzazione sia possibile. Inoltre, molta fiducia è riposta nell'infrastruttura centrale.

Il protocollo fornisce l'opzione che l'associazione nome server - chiave host non venga controllata quando ci si connette all'host per la prima volta. Ciò consente la comunicazione senza comunicazione preventiva delle chiavi host o certificazione. La connessione fornisce comunque protezione contro l'ascolto passivo; tuttavia, diventa vulnerabile agli attacchi attivi man-in-the-middle. Le implementazioni NON DOVREBBERO normalmente consentire tali connessioni per impostazione predefinita, poiché pongono un potenziale problema di sicurezza. Tuttavia, poiché non è disponibile un'infrastruttura di chiavi ampiamente distribuita su Internet al momento della stesura di questo documento, questa opzione rende il protocollo molto più utilizzabile durante il periodo di transizione fino all'emergere di tale infrastruttura, fornendo comunque un livello di sicurezza molto più elevato rispetto a quello offerto dalle soluzioni più vecchie (ad esempio, telnet [RFC0854] e rlogin [RFC1282]).

Le implementazioni DOVREBBERO cercare di fare del loro meglio per verificare le chiavi host. Un esempio di strategia possibile è accettare una chiave host senza controllo solo la prima volta che un host è connesso, salvare la chiave in un database locale e confrontare con quella chiave su tutte le connessioni future a quell'host.

Le implementazioni POSSONO fornire metodi aggiuntivi per verificare la correttezza delle chiavi host, ad esempio, un'impronta digitale esadecimale derivata dall'hash SHA-1 [FIPS-180-2] della chiave pubblica. Tali impronte digitali possono essere facilmente verificate utilizzando il telefono o altri canali di comunicazione esterni.

Tutte le implementazioni DOVREBBERO fornire un'opzione per non accettare chiavi host che non possono essere verificate.

I membri di questo gruppo di lavoro ritengono che la "facilità d'uso" sia fondamentale per l'accettazione da parte dell'utente finale delle soluzioni di sicurezza, e nessun miglioramento della sicurezza viene ottenuto se le nuove soluzioni non vengono utilizzate. Pertanto, fornire l'opzione di non controllare la chiave host del server è ritenuto migliorare la sicurezza complessiva di Internet, anche se riduce la sicurezza del protocollo nelle configurazioni in cui è consentito.

4.2. Extensibility (Estensibilità)

Crediamo che il protocollo si evolverà nel tempo e che alcune organizzazioni vorranno utilizzare i propri metodi di crittografia, autenticazione e/o scambio di chiavi. La registrazione centrale di tutte le estensioni è ingombrante, specialmente per funzionalità sperimentali o classificate. D'altra parte, non avere una registrazione centrale porta a conflitti negli identificatori di metodo, rendendo difficile l'interoperabilità.

Abbiamo scelto di identificare algoritmi, metodi, formati e protocolli di estensione con nomi testuali che sono di un formato specifico. I nomi DNS vengono utilizzati per creare spazi dei nomi locali in cui estensioni sperimentali o classificate possono essere definite senza timore di conflitti con altre implementazioni.

Un obiettivo di progettazione è stato mantenere il protocollo di base il più semplice possibile e richiedere il minor numero possibile di algoritmi. Tuttavia, tutte le implementazioni DEVONO supportare un insieme minimo di algoritmi per garantire l'interoperabilità (ciò non implica che la policy locale su tutti gli host consentirebbe necessariamente questi algoritmi). Gli algoritmi obbligatori sono specificati nei documenti di protocollo pertinenti.

Algoritmi, metodi, formati e protocolli di estensione aggiuntivi possono essere definiti in documenti separati. Vedere Sezione 6, Algorithm Naming, per maggiori informazioni.

4.3. Policy Issues (Questioni di policy)

Il protocollo consente una negoziazione completa di crittografia, integrità, scambio di chiavi, compressione e algoritmi e formati di chiavi pubbliche. Gli algoritmi di crittografia, integrità, chiavi pubbliche e compressione possono essere diversi per ciascuna direzione.

Le seguenti questioni di policy DOVREBBERO essere affrontate nei meccanismi di configurazione di ciascuna implementazione:

Algoritmi di crittografia, integrità e compressione, separatamente per ciascuna direzione. La policy DEVE specificare qual è l'algoritmo preferito (ad esempio, il primo algoritmo elencato in ciascuna categoria).
Algoritmi di chiavi pubbliche e metodo di scambio di chiavi da utilizzare per l'autenticazione host. L'esistenza di chiavi host fidate per diversi algoritmi di chiavi pubbliche influisce anche su questa scelta.
I metodi di autenticazione che devono essere richiesti dal server per ciascun utente. La policy del server PUÒ richiedere autenticazione multipla per alcuni o tutti gli utenti. Gli algoritmi richiesti POSSONO dipendere dalla posizione da cui l'utente sta cercando di ottenere l'accesso.
Le operazioni che l'utente è autorizzato a eseguire utilizzando il protocollo di connessione. Alcune questioni sono correlate alla sicurezza; ad esempio, la policy NON DOVREBBE consentire al server di avviare sessioni o eseguire comandi sulla macchina client e NON DEVE consentire connessioni all'agente di autenticazione a meno che l'inoltro di tali connessioni non sia stato richiesto. Altre questioni, come quali porte TCP/IP possono essere inoltrate e da chi, sono chiaramente questioni di policy locale. Molte di queste questioni possono comportare l'attraversamento o l'aggiramento di firewall e sono correlate alla policy di sicurezza locale.

4.4. Security Properties (Proprietà di sicurezza)

L'obiettivo principale del protocollo SSH è migliorare la sicurezza su Internet. Tenta di farlo in un modo facile da implementare, anche a costo della sicurezza assoluta.

Tutti gli algoritmi di crittografia, integrità e chiavi pubbliche utilizzati sono algoritmi ben noti e ben consolidati.
Tutti gli algoritmi sono utilizzati con dimensioni di chiave crittograficamente solide che si ritiene forniscano protezione anche contro gli attacchi crittoanalitici più forti per decenni.
Tutti gli algoritmi sono negoziati, e nel caso in cui qualche algoritmo venga violato, è facile passare a qualche altro algoritmo senza modificare il protocollo di base.

Sono state fatte concessioni specifiche per rendere più facile una distribuzione diffusa e rapida. Il caso particolare in cui ciò si verifica è la verifica che la chiave host del server appartenga realmente all'host desiderato; il protocollo consente di omettere la verifica, ma ciò NON è RACCOMANDATO. Si ritiene che ciò migliori significativamente l'usabilità a breve termine, fino all'emergere di infrastrutture di chiavi pubbliche Internet diffuse.

4.5. Localization and Character Set Support (Localizzazione e supporto set di caratteri)

Per la maggior parte, i protocolli SSH non trasmettono direttamente testo che verrebbe visualizzato all'utente. Tuttavia, ci sono alcuni luoghi in cui tali dati potrebbero essere trasmessi. Quando applicabile, il set di caratteri per i dati DEVE essere esplicitamente specificato. Nella maggior parte dei luoghi, viene utilizzata la codifica ISO-10646 UTF-8 [RFC3629]. Quando applicabile, viene fornito anche un campo per un tag di lingua [RFC3066].

Un grande problema è il set di caratteri della sessione interattiva. Non esiste una soluzione chiara, poiché applicazioni diverse possono visualizzare dati in formati diversi. Diversi tipi di emulazione di terminale possono anche essere impiegati nel client, e il set di caratteri da utilizzare è effettivamente determinato dall'emulazione di terminale. Pertanto, non è previsto un posto per specificare direttamente il set di caratteri o la codifica per i dati di sessione del terminale. Tuttavia, il tipo di emulazione di terminale (ad esempio, "vt100") viene trasmesso al sito remoto, e specifica implicitamente il set di caratteri e la codifica. Le applicazioni utilizzano tipicamente il tipo di terminale per determinare quale set di caratteri usano, o il set di caratteri viene determinato utilizzando mezzi esterni. L'emulazione di terminale può anche consentire la configurazione del set di caratteri predefinito. In ogni caso, il set di caratteri per la sessione del terminale è considerato principalmente una questione locale del client.

I nomi interni utilizzati per identificare algoritmi o protocolli normalmente non vengono mai visualizzati agli utenti e devono essere in US-ASCII.

I nomi utente client e server sono intrinsecamente vincolati da ciò che il server è disposto ad accettare. Potrebbero, tuttavia, essere occasionalmente visualizzati in log, rapporti, ecc. Essi DEVONO essere codificati utilizzando ISO 10646 UTF-8, ma altre codifiche potrebbero essere richieste in alcuni casi. Spetta al server decidere come mappare i nomi utente ai nomi utente accettati. Si RACCOMANDA un confronto binario bit per bit diretto.

Per scopi di localizzazione, il protocollo tenta di minimizzare il numero di messaggi testuali trasmessi. Quando presenti, tali messaggi si riferiscono tipicamente a errori, informazioni di debug o alcuni dati configurati esternamente. Per i dati che vengono normalmente visualizzati, DOVREBBE essere possibile recuperare un messaggio localizzato invece del messaggio trasmesso utilizzando un codice numerico. I messaggi rimanenti DOVREBBERO essere configurabili.