4. Requisiti di conformità

Per garantire che tutte le implementazioni di IKEv2 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 con successo l'instaurazione delle SA. Pertanto, una particolare implementazione può essere configurata con una serie di restrizioni riguardanti algoritmi e autorità fidate che impediranno l'interoperabilità universale.

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

La capacità di negoziare SA attraverso un NAT e di tunnelizzare la SA ESP risultante su UDP.
La capacità di richiedere (e rispondere a una richiesta di) un indirizzo IP temporaneo all'estremità remota di un tunnel.
La capacità di supportare l'autenticazione basata su EAP.
La capacità di supportare dimensioni della finestra superiori a uno.
La capacità di stabilire multiple SA ESP o AH all'interno di una singola IKE SA.
La capacità di rieffettuare il rekeying delle SA.

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

Ogni implementazione DEVE essere in grado di eseguire gli scambi IKE_SA_INIT e IKE_AUTH di quattro messaggi stabilendo due SA (una per IKE, una per ESP o AH). Le implementazioni POSSONO essere solo iniziatrici o solo rispondenti se appropriate per la loro 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 (notare che nel contesto di una IKE SA, un messaggio "vuoto" consiste in un header IKE seguito da un payload Encrypted senza payload contenuti). Un'implementazione minima PUÒ supportare lo scambio CREATE_CHILD_SA solo per quanto riguarda il riconoscimento delle richieste e il loro rifiuto con un payload Notify di tipo NO_ADDITIONAL_SAS. Un'implementazione minima non deve essere in grado di iniziare scambi CREATE_CHILD_SA o INFORMATIONAL. Quando una SA scade (in base ai valori configurati localmente di durata o ottetti trasmessi), l'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 di eliminare invece la vecchia SA e crearne una nuova.

Le implementazioni non sono tenute a supportare la richiesta di indirizzi IP temporanei o la risposta a tali richieste. Se un'implementazione supporta l'emissione di tali richieste e la sua politica richiede l'uso di indirizzi IP temporanei, DEVE includere un payload CP 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 opzionali. 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 il leasing 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 detta conforme a questa specifica, DEVE essere possibile configurarla per accettare quanto segue:

Infrastruttura a chiave pubblica che utilizza certificati X.509 (PKIX) contenenti e firmati da chiavi RSA di dimensione 1024 o 2048 bit, dove l'ID passato è uno qualsiasi tra ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR o ID_DER_ASN1_DN.
Autenticazione a chiave condivisa dove l'ID passato è uno qualsiasi tra ID_KEY_ID, ID_FQDN o ID_RFC822_ADDR.
Autenticazione in cui il risponditore è autenticato utilizzando certificati PKIX e l'iniziatore è autenticato utilizzando l'autenticazione a chiave condivisa.