2.18. Ricompilazione delle chiavi delle IKE SA usando uno scambio CREATE_CHILD_SA

2.18. Ricompilazione delle chiavi delle IKE SA usando uno scambio CREATE_CHILD_SA

Lo scambio CREATE_CHILD_SA può essere usato per ricompilare le chiavi di una IKE SA esistente (vedere sezioni 1.3.2 e 2.8). I nuovi SPI di iniziatore e risponditore sono forniti nei campi SPI delle strutture di proposta dentro i payload Security Association (SA) (non nei campi SPI nell'header IKE). I payload TS sono omessi quando si ricompilano le chiavi di una IKE SA. SKEYSEED per la nuova IKE SA è calcolato usando SK_d della IKE SA esistente come segue:

SKEYSEED = prf(SK_d (old), g^ir (new) | Ni | Nr)

dove g^ir (new) è il segreto condiviso dallo scambio ephemeral Diffie-Hellman di questo scambio CREATE_CHILD_SA (rappresentato come una stringa di ottetti in ordine big endian riempita con zeri se necessario per renderla della lunghezza del modulo) e Ni e Nr sono i due nonce spogliati di qualsiasi header.

La vecchia IKE SA e la nuova IKE SA possono aver selezionato un PRF diverso. Poiché lo scambio di ricompilazione appartiene alla vecchia IKE SA, è il PRF della vecchia IKE SA che è usato per generare SKEYSEED.

La ragione principale per ricompilare le chiavi della IKE SA è assicurare che la compromissione di vecchio materiale di chiave non fornisca informazioni sulle chiavi correnti, o vice versa. Pertanto, le implementazioni DEVONO eseguire un nuovo scambio Diffie-Hellman quando ricompilano le chiavi della IKE SA. In altre parole, un iniziatore NON DEVE proporre il valore "NONE" per la trasformazione Diffie-Hellman, e un risponditore NON DEVE accettare tale proposta. Questo significa che uno scambio riuscito che ricompila le chiavi della IKE SA include sempre i payload KEi/KEr.

La nuova IKE SA DEVE resettare i suoi contatori di messaggi a 0.

SK_d, SK_ai, SK_ar, SK_ei, e SK_er sono calcolati da SKEYSEED come specificato nella sezione 2.14, usando SPIi, SPIr, Ni, e Nr dal nuovo scambio, e usando il PRF della nuova IKE SA.