4. Conformance Requirements (Requisiti di conformità)

4. Conformance Requirements (Requisiti di conformità)

Per garantire che tutte le implementazioni di IKEv2 (Internet Key Exchange Protocol Version 2) possano interoperare, esistono requisiti « MUST support » oltre a quelli elencati altrove. Naturalmente IKEv2 è un protocollo di sicurezza e una delle sue funzioni principali è consentire solo alle parti autorizzate di completare l'istituzione delle SA (Security Associations, associazioni di sicurezza). Una particolare implementazione può quindi essere configurata con varie restrizioni su algoritmi e autorità attendibili che impediranno un'interoperabilità universale.

IKEv2 è progettato per consentire implementazioni minime in grado di interoperare con tutte le implementazioni conformi. Le seguenti funzionalità possono essere omesse in un'implementazione minima:

• Capacità di negoziare SA attraverso un NAT (Network Address Translation) e incapsulare la risultante SA ESP su UDP.

• Capacità di richiedere (e rispondere a una richiesta di) un indirizzo IP temporaneo all'estremità remota di un tunnel.

• Capacità di supportare l'autenticazione basata su EAP (Extensible Authentication Protocol).

• Capacità di supportare dimensioni di finestra maggiori di uno.

• Capacità di stabilire più SA ESP o AH (Authentication Header) all'interno di una singola SA IKE.

• Capacità di rinnovare le chiavi delle SA (rekeying).

Per garantire l'interoperabilità, tutte le implementazioni DEVONO essere in grado di analizzare tutti i tipi di payload (se solo per saltarli) e di ignorare i tipi di payload non supportati a meno che il bit critical non sia impostato nell'intestazione del payload. Se il bit critical è impostato in un'intestazione di payload non supportata, tutte le implementazioni DEVONO rifiutare i messaggi che contengono tali payload.

Ogni implementazione DEVE essere in grado di eseguire scambi IKE_SA_INIT e IKE_AUTH di quattro messaggi che stabiliscono due SA (una per IKE, una per ESP o AH). Le implementazioni POSSONO essere solo iniziatrici o solo risponditrici se appropriato per la piattaforma. Ogni implementazione DEVE essere in grado di rispondere a uno scambio INFORMATIONAL, ma un'implementazione minima PUÒ rispondere a qualsiasi richiesta nello scambio INFORMATIONAL con una risposta vuota (nel contesto di una SA IKE, un messaggio « vuoto » consiste in un'intestazione IKE seguita da un payload crittografato senza payload interni). Un'implementazione minima PUÒ supportare lo scambio CREATE_CHILD_SA solo nella misura in cui riconosce le richieste e le rifiuta con un payload Notify di tipo NO_ADDITIONAL_SAS. Un'implementazione minima non deve necessariamente poter avviare scambi CREATE_CHILD_SA o INFORMATIONAL. Quando una SA scade (in base a valori configurati localmente di durata o ottetti trasmessi), un'implementazione PUÒ tentare di rinnovarla con uno scambio CREATE_CHILD_SA oppure PUÒ eliminare (chiudere) la vecchia SA e crearne una nuova. Se il risponditore rifiuta la richiesta CREATE_CHILD_SA con una notifica NO_ADDITIONAL_SAS, l'implementazione DEVE essere in grado invece di eliminare la vecchia SA e crearne una nuova.

Le implementazioni non sono tenute a supportare la richiesta di indirizzi IP temporanei né a rispondere a tali richieste. Se un'implementazione supporta l'invio di tali richieste e la sua politica richiede indirizzi IP temporanei, DEVE includere un payload CP (Configuration) nel primo messaggio dello scambio IKE_AUTH contenente almeno un campo di tipo INTERNAL_IP4_ADDRESS o INTERNAL_IP6_ADDRESS. Tutti gli altri campi sono facoltativi. Se un'implementazione supporta la risposta a tali richieste, DEVE analizzare il payload CP di tipo CFG_REQUEST nel primo messaggio dello scambio IKE_AUTH e riconoscere un campo di tipo INTERNAL_IP4_ADDRESS o INTERNAL_IP6_ADDRESS. Se supporta l'assegnazione di un indirizzo del tipo appropriato, DEVE restituire un payload CP di tipo CFG_REPLY contenente un indirizzo del tipo richiesto. Il risponditore può includere qualsiasi altro attributo correlato.

Affinché un'implementazione sia definita conforme a questa specifica, DEVE essere possibile configurarla per accettare quanto segue:

• Infrastruttura a chiave pubblica X.509 PKIX (Public Key Infrastructure using X.509) con certificati contenenti e firmati da chiavi RSA di 1024 o 2048 bit, dove l'ID passato è uno tra ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR o ID_DER_ASN1_DN.

• Autenticazione a chiave condivisa dove l'ID passato è uno tra ID_KEY_ID, ID_FQDN o ID_RFC822_ADDR.

• Autenticazione in cui il risponditore è autenticato con certificati PKIX e l'iniziatore con chiave condivisa.