2.7. Negoziazione degli algoritmi

Ogni algoritmo crittografico supportato da un'implementazione DEVE essere specificato con un particolare tipo di attributo SA, un valore di ID di trasformazione e tutti i parametri richiesti (come la lunghezza della chiave). Questi sono elencati in [IKEV2IANA].

In una singola proposta SA, un'implementazione può elencare più insiemi di trasformazioni compatibili con una proposta. I membri di ciascun insieme DEVONO essere tutti compatibili. Se viene elencato l'ID di trasformazione "NONE" (valore 0), tale ID di trasformazione DEVE essere l'unica trasformazione elencata per quel tipo. NONE è ammesso solo per gli algoritmi di integrità. Un algoritmo di integrità NONE significa che non viene fornita alcuna protezione di integrità, a meno che non venga utilizzato un algoritmo di cifratura in modalità combinata (vedere sezione 3.3.2). Se viene selezionato un algoritmo di cifratura in modalità combinata, non dovrebbe essere specificato un algoritmo di integrità separato per l'algoritmo di cifratura, e MUST dovrebbe essere NONE (vedere sezione 3.3.2). NONE DEVE essere rifiutato in tutti gli altri casi.

L'iniziatore DEVE proporre almeno una proposta supportata dalla sua implementazione, e il risponditore DEVE accettare la prima proposta supportata dalla sua implementazione. In caso di molteplici proposte compatibili, il comportamento del risponditore è specifico dell'implementazione. L'iniziatore DEVE includere solo proposte supportate dalla sua implementazione. Il risponditore PUÒ rifiutare una proposta valida se ha già ricevuto e proposto una proposta preferita dal peer in un precedente scambio IKE.

Per negoziare ciascun protocollo (IKE o AH o ESP), DEVE esserci almeno una proposta nel payload SA, e ciascuna proposta DEVE contenere almeno una trasformazione di ciascun tipo: al massimo una trasformazione per ciascun tipo (cifratura, integrità, PRF e DH), a meno che multiple trasformazioni non possano essere negoziate separatamente (ad esempio un algoritmo di cifratura in modalità combinata, che include la protezione di integrità ma non come trasformazione separata). L'insieme crittografico stesso può essere combinato, ma notate che gli algoritmi combinati sono rappresentati come una singola trasformazione nel payload SA.

2.7.1. Selezione dei cifrari

Ciascuna implementazione DEVE implementare i seguenti cifrari:

Cifratura: ENCR_AES_CBC nonché l'algoritmo di cifratura AEAD ENCR_AES_GCM_16 (vedere sezione 3.3.2). Le implementazioni POSSONO inoltre implementare ENCR_AES_CTR come trasformazione AES alternativa. Le implementazioni POSSONO implementare ENCR_3DES, ENCR_DES, ENCR_CAST ed ENCR_BLOWFISH, ma essi sono obsoleti e non sono raccomandati (SHOULD NOT) per le nuove implementazioni.
Funzione pseudo-casuale: PRF_HMAC_SHA1. Le implementazioni DEVONO implementare PRF_HMAC_SHA1, e POSSONO implementare PRF_AES128_XCBC e PRF_HMAC_SHA2_256 o PRF_HMAC_SHA2_384 o PRF_HMAC_SHA2_512.
Integrità: AUTH_HMAC_SHA1_96. Le implementazioni DEVONO implementare AUTH_HMAC_SHA1_96, e POSSONO implementare AUTH_AES_XCBC_96, AUTH_HMAC_SHA2_256_128 o AUTH_HMAC_SHA2_384_192 o AUTH_HMAC_SHA2_512_256.
Gruppi DH a dominio finito: le implementazioni DEVONO implementare il gruppo MODP a 1024 bit 2 e il gruppo EC 19. Le implementazioni POSSONO implementare il gruppo MODP a 2048 bit 14 (nonché i gruppi EC 20, 21, 23, 24 o 25) come alternativa. L'interoperabilità tra i gruppi EC e il gruppo 2 non è ancora stabilita, ma il vantaggio della standardizzazione è di consentire ai deployment di standardizzarsi su un gruppo dato, nel caso in cui implementazioni più recenti supportassero solo i gruppi EC.
Le implementazioni POSSONO implementare altri gruppi Diffie-Hellman, ma non è RICHIESTO.

Sembra che questo documento non dovrebbe richiedere l'implementazione di algoritmi specifici, poiché i progressi della crittoanalisi potrebbero renderli obsoleti; tuttavia, se tutte le implementazioni scegliessero diversi insiemi di algoritmi opzionali, l'interoperabilità sarebbe impossibile. Pertanto, questo documento definisce un insieme minimo di algoritmi obbligatori e richiede che i nuovi algoritmi siano negoziati con questi algoritmi. Pertanto, tutti gli algoritmi richiesti per un'implementazione dovrebbero essere obbligatori, standardizzati (come sopra), oppure dovrebbero implementare uno degli algoritmi obbligatori elencati sopra.

Le implementazioni DOVREBBERO supportare i certificati X.509 v3 per l'identificazione nonché RSA e ECDSA irreversibile (come descritto in [PKI] e [EAIKEv2]) per la firma (nel payload AUTH). Per supportare EAP, le implementazioni DEVONO supportare l'autenticazione EAP. Le implementazioni che supportano EAP DOVREBBERO supportare il metodo EAP EAP-MSCHAPv2, e POSSONO supportare altri metodi. Il supporto dell'autenticazione con chiave pre-condivisa è fortemente RACCOMANDATO.

2.7.2. Rinegoziazione

In una IKE SA, a meno che non vengano prese altre disposizioni (ad esempio, tramite uno scambio CREATE_CHILD_SA "volatile", vedere sezione 2.18), il cifrario degli algoritmi di cifratura negoziati non dovrebbe (SHOULD NOT) cambiare durante la vita della SA. Una rinegoziazione PUÒ essere avviata per sostituire una SA in scadenza, oppure per negoziare nuove chiavi (basate su certificato) o una nuova identità per una IKE SA esistente, oppure per modificare gli attributi della IKE SA (ad esempio, passare dall'autenticazione con chiave pre-condivisa all'autenticazione con certificato). Durante la rinegoziazione, quasi l'intero flusso di messaggi viene ripetuto, eccetto che esso è completato all'interno della parte protetta della IKE SA esistente anziché in chiaro.

Poiché la rinegoziazione utilizza lo scambio CREATE_CHILD_SA, ha l'effetto di creare una nuova child SA per la IKE SA esistente. L'iniziatore PUÒ non specificare alcun payload SA (incluso l'ID di protocollo) nello scambio CREATE_CHILD_SA, per indicare che desidera rinegoziare la IKE SA stessa piuttosto che creare una nuova child SA. In questo caso, quando lo scambio CREATE_CHILD_SA è utilizzato per rinegoziare la IKE SA, NON DEVE essere utilizzato per creare simultaneamente una child SA. Questo tipo di scambio è anche chiamato rinegoziazione "di tipo 1".

Se l'iniziatore include un payload SA nello scambio CREATE_CHILD_SA, tale payload SA DEVE essere utilizzato per creare una child SA (o ulteriori child SA), mentre si rinegozia la IKE SA, e il risponditore DEVE accettarlo. Questo tipo di scambio è anche chiamato rinegoziazione "di tipo 2". Il supporto della rinegoziazione di tipo 2 non è RICHIESTO.

2.7.3. Metodi di autenticazione supportati

Le implementazioni DEVONO supportare i seguenti metodi di autenticazione:

Basata su firma digitale (vedere sezione 3.8), utilizzando gli algoritmi RSA o ECDSA irreversibile, come descritto in [PKI] e [EAIKEv2].
Chiave pre-condivisa (vedere sezioni 2.15 e 3.8).
Extensible Authentication Protocol (EAP), come descritto in [EAP].

Le implementazioni POSSONO supportare altri metodi di autenticazione, ma non è RICHIESTO.