Passa al contenuto principale

3.14. Encrypted Payload (Payload crittografato)

3.14. Encrypted Payload (Payload crittografato)​

L'Encrypted payload, indicato come SK {...} in questo documento, contiene altri payload in forma crittografata. Se è presente un Encrypted payload in un messaggio, DEVE essere l'ultimo payload del messaggio. Spesso è l'unico payload del messaggio. Questo payload è anche detto payload «Encrypted and Authenticated».

Gli algoritmi di crittografia e protezione dell'integrità sono negoziati durante l'istituzione dell'IKE SA, e le chiavi sono calcolate come specificato nelle sezioni 2.14 e 2.18.

Questo documento specifica l'elaborazione crittografica degli Encrypted payload usando un cifrario a blocchi in modalità CBC e un algoritmo di controllo dell'integrità che calcola un checksum di lunghezza fissa su un messaggio di dimensione variabile. Il progetto è modellato sugli algoritmi ESP descritti in RFC 2104 [HMAC], 4303 [ESP] e 2451 [ESPCBC]. Questo documento specifica completamente l'elaborazione crittografica dei dati IKE, ma quei documenti vanno consultati per la motivazione di progetto. Documenti futuri POSSONO specificare l'elaborazione degli Encrypted payload per altri tipi di trasformazione, come la crittografia in modalità contatore e gli algoritmi di crittografia autenticata. I peer NON DEVONO negoziare trasformazioni per cui non esiste tale specifica.

Quando si usa un algoritmo di crittografia autenticata per proteggere l'IKE SA, la costruzione dell'Encrypted payload è diversa da quanto descritto qui. Vedere [AEAD] per maggiori informazioni sugli algoritmi di crittografia autenticata e sul loro uso in IKEv2.

Il tipo di payload per un Encrypted payload è quarantasei (46). L'Encrypted payload consiste nell'intestazione generica IKE dei payload seguita dai campi seguenti:

                    1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Initialization Vector                     |
|         (length is block size for encryption algorithm)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    Encrypted IKE Payloads                     ~
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |             Padding (0-255 octets)            |
+-+-+-+-+-+-+-+                               +-+-+-+-+-+-+-+-+
|                                               |  Pad Length   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    Integrity Checksum Data                    ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figura 21: Formato dell'Encrypted payload

  • Next Payload - Il tipo di payload del primo payload incorporato. Si tratta di un'eccezione al formato di intestazione standard, poiché l'Encrypted payload è l'ultimo payload del messaggio e quindi il campo Next Payload sarebbe normalmente zero. Ma poiché il contenuto di questo payload è costituito da payload incorporati e non c'era un posto naturale per il tipo del primo, quel tipo è posto qui.

  • Payload Length - Include le lunghezze dell'intestazione, del vettore di inizializzazione (IV), degli IKE payload crittografati, del Padding, del Pad Length e degli Integrity Checksum Data.

  • Initialization Vector - Per i cifrari in modalità CBC, la lunghezza dell'IV è uguale alla lunghezza di blocco dell'algoritmo di crittografia sottostante. I mittenti DEVONO selezionare un nuovo IV imprevedibile per ogni messaggio; i destinatari DEVONO accettare qualsiasi valore. Si consiglia di consultare [MODES] per la generazione degli IV. In particolare, usare l'ultimo blocco di testo cifrato del messaggio precedente non è considerato imprevedibile. Per modalità diverse da CBC, il formato e l'elaborazione dell'IV sono specificati nel documento che definisce l'algoritmo e la modalità di crittografia.

  • Gli IKE payload sono come specificato prima in questa sezione. Questo campo è crittografato con il cifrario negoziato.

  • Il Padding PUÒ contenere qualsiasi valore scelto dal mittente e DEVE avere una lunghezza tale che la combinazione dei payload, del Padding e del Pad Length sia un multiplo della dimensione di blocco della crittografia. Questo campo è crittografato con il cifrario negoziato.

  • Pad Length è la lunghezza del campo Padding. Il mittente DOVREBBE impostare Pad Length al valore minimo che rende la combinazione di payload, Padding e Pad Length un multiplo della dimensione di blocco, ma il destinatario DEVE accettare qualsiasi lunghezza che produca un allineamento corretto. Questo campo è crittografato con il cifrario negoziato.

  • Integrity Checksum Data è il checksum crittografico dell'intero messaggio dall'intestazione IKE fissa fino al Pad Length. Il checksum DEVE essere calcolato sul messaggio crittografato. La sua lunghezza è determinata dall'algoritmo di integrità negoziato.

Ultimo aggiornamento il