2.15. Autenticazione della IKE SA

Quando non si usa l'autenticazione estensibile (vedere sezione 2.16), i peer vengono autenticati facendo sì che ciascuno firmi (o calcoli un MAC usando un segreto condiviso riempito come chiave, come descritto più avanti in questa sezione) un blocco di dati. In questi calcoli, IDi' e IDr' sono l'intero payload ID escluso l'header fisso. Per il risponditore, gli ottetti da firmare iniziano con il primo ottetto del primo SPI nell'header del secondo messaggio (risposta IKE_SA_INIT) e terminano con l'ultimo ottetto dell'ultimo payload nel secondo messaggio. Ad essi viene aggiunto (ai fini del calcolo della firma) il nonce Ni dell'iniziatore (solo il valore, non il payload che lo contiene), e il valore prf(SK_pr, IDr'). Notare che né il nonce Ni né il valore prf(SK_pr, IDr') vengono trasmessi. Similmente, l'iniziatore firma il primo messaggio (richiesta IKE_SA_INIT), iniziando con il primo ottetto del primo SPI nell'header e terminando con l'ultimo ottetto dell'ultimo payload. Ad esso viene aggiunto (ai fini del calcolo della firma) il nonce Nr del risponditore, e il valore prf(SK_pi, IDi'). È critico per la sicurezza dello scambio che ciascun lato firmi il nonce dell'altro lato.

Gli ottetti firmati dall'iniziatore possono essere descritti come:

Gli ottetti firmati dal risponditore possono essere descritti come:

Notare che tutti i payload sono inclusi sotto la firma, incluso qualsiasi tipo di payload non definito in questo documento. Se il primo messaggio dello scambio viene inviato multiple volte (come con un cookie di risponditore e/o un gruppo Diffie-Hellman diverso), è l'ultima versione del messaggio quella firmata.

Opzionalmente, i messaggi 3 e 4 POSSONO includere un certificato, o una catena di certificati che fornisce evidenza che la chiave usata per calcolare una firma digitale appartiene al nome nel payload ID. La firma o il MAC verrà calcolato usando gli algoritmi dettati dal tipo di chiave usato dal firmatario, e specificati dal campo Auth Method nel payload Authentication. Non è richiesto (REQUIRED) che l'iniziatore e il risponditore firmino con gli stessi algoritmi crittografici. La scelta degli algoritmi crittografici dipende dal tipo di chiave che ciascuno possiede. In particolare, l'iniziatore può usare una chiave condivisa mentre il risponditore può avere una chiave di firma pubblica e un certificato. Sarà comune (ma non richiesto) che, se un segreto condiviso è usato per l'autenticazione, la stessa chiave sia usata in entrambe le direzioni.

Notare che è una pratica comune ma tipicamente insicura avere un segreto condiviso derivato unicamente da una password scelta dall'utente senza incorporare un'altra fonte di casualità. Questo è tipicamente insicuro perché le password scelte dagli utenti hanno una probabilità scarsa di avere imprevedibilità sufficiente per resistere ad attacchi a dizionario e questi attacchi non sono prevenuti in questo metodo di autenticazione. (Le applicazioni che usano l'autenticazione basata su password per il bootstrapping e la IKE SA dovrebbero usare il metodo di autenticazione nella sezione 2.16, che è progettato per prevenire attacchi a dizionario offline.) La chiave pre-condivisa deve contenere tanta imprevedibilità quanto la chiave più forte negoziata. Nel caso di una chiave pre-condivisa, il valore AUTH è calcolato come:

Per l'iniziatore: AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), ) Per il risponditore: AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), )

dove la stringa "Key Pad for IKEv2" è di 17 caratteri ASCII senza terminazione nulla. Il segreto condiviso può essere di lunghezza variabile. La stringa di pad è aggiunta così che se il segreto condiviso è derivato da una password, l'implementazione IKE non ha bisogno di memorizzare la password in chiaro, ma piuttosto può memorizzare il valore prf(Shared Secret,"Key Pad for IKEv2"), che non potrebbe essere usato come equivalente password per protocolli diversi da IKEv2. Come notato sopra, derivare il segreto condiviso da una password non è sicuro. Questa costruzione è usata perché è anticipato che le persone lo faranno comunque. L'interfaccia di gestione tramite la quale il segreto condiviso è fornito DEVE accettare stringhe ASCII di almeno 64 ottetti e NON DEVE aggiungere una terminazione nulla prima di usarle come segreti condivisi. Essa DEVE anche accettare una codifica esadecimale del segreto condiviso. L'interfaccia di gestione PUÒ accettare altre codifiche se l'algoritmo per tradurre la codifica in una stringa binaria è specificato.

Ci sono due tipi di autenticazione EAP (descritti nella sezione 2.16), e ciascun tipo usa valori differenti nei calcoli AUTH mostrati sopra. Se il metodo EAP è generatore di chiave, sostituire il master session key (MSK) per il segreto condiviso nel calcolo. Per i metodi non generatore di chiave, sostituire rispettivamente SK_pi e SK_pr per il segreto condiviso nei due calcoli AUTH.

2.15. Autenticazione della IKE SA​

2.15. Autenticazione della IKE SA