3.3. Payload SA

3.3. Payload SA

Il payload Security Association (SA), indicato come SA in questo documento, serve a negoziare gli attributi di un'associazione di sicurezza. L'assemblaggio di un payload SA richiede grande pazienza. Un payload SA può contenere più proposte (Proposals). Se sono presenti più proposte, DEVONO essere ordinate dalla più preferita alla meno preferita. Ogni proposta contiene un singolo protocollo IPsec (il protocollo può essere IKE, ESP o AH) e ciascun protocollo può contenere più trasformazioni (Transforms), ciascuna delle quali può contenere più attributi (Attributes). Durante l'analisi di una SA, l'implementazione DEVE verificare che la Payload Length totale sia coerente con le lunghezze e i contatori interni a tale payload. Proposte, trasformazioni e attributi hanno ciascuno una codifica a lunghezza variabile. Sono organizzati in modo annidato, in modo che la Payload Length della SA comprenda il contenuto unito delle informazioni SA, proposta, trasformazione e attributo. La lunghezza di una proposta comprende tutte le trasformazioni e gli attributi in essa contenuti. La lunghezza di una trasformazione comprende tutti gli attributi in essa contenuti.

La sintassi di associazione di sicurezza, proposta, trasformazione e attributo è basata su ISAKMP; la loro semantica tuttavia differisce. La ragione di questa complessità e struttura gerarchica è di consentire la codifica di più combinazioni possibili di algoritmi in un'unica SA. A volte è necessario scegliere tra più algoritmi, a volte si tratta di una combinazione di algoritmi. Ad esempio, l'iniziatore potrebbe voler proporre ESP associato a (3DES e HMAC_MD5) oppure (AES e HMAC_SHA1).

Uno dei motivi per cui la semantica del payload SA è cambiata rispetto a ISAKMP e IKEv1 è rendere l'codifica più compatta nei casi comuni.

La struttura di proposta contiene un numero di proposta e un identificativo di protocollo IPsec. Ciascuna struttura DEVE avere un numero superiore di 1 alla struttura precedente. La prima proposta nel payload SA dell'iniziatore DEVE avere il numero di proposta 1 (uno). Uno dei motivi per l'uso di più proposte è proporre simultaneamente algoritmi di cifratura standard e algoritmi in modalità combinata (combined-mode). Un algoritmo in modalità combinata integra integrità e cifratura in un singolo algoritmo di cifratura e DEVE o non fornire alcun algoritmo di integrità o fornirne uno singolo « none », essendo la mancata fornitura dell'algoritmo di integrità il metodo RACCOMANDATO. Se l'iniziatore desidera proporre simultaneamente algoritmi in modalità combinata e normali, DEVE includere due proposte: una contenente tutti gli algoritmi in modalità combinata, l'altra contenente tutti gli algoritmi normali con algoritmi di integrità. Ad esempio, una tale proposta avrebbe due strutture di proposta. La proposta 1 è ESP con AES-128, AES-192 e AES-256 in modalità CBC, con algoritmo di integrità HMAC-SHA1-96 o XCBC-96; la proposta 2 è AES-128 o AES-256 in modalità GCM con un valore di controllo di integrità (ICV) di 8 ottetti. Entrambe le proposte consentono, senza richiederla, l'uso di ESN (numero di sequenza esteso). Questo può essere rappresentato così:

SA Payload | +--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4, | | 7 transforms, SPI = 0x052357bb ) | | | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | | +-- Attribute ( Key Length = 128 ) | | | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | | +-- Attribute ( Key Length = 192 ) | | | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | | +-- Attribute ( Key Length = 256 ) | | | +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 ) | +-- Transform INTEG ( Name = AUTH_AES_XCBC_96 ) | +-- Transform ESN ( Name = ESNs ) | +-- Transform ESN ( Name = No ESNs ) | +--- Proposal #2 ( Proto ID = ESP(3), SPI size = 4, | 4 transforms, SPI = 0x35a1d6f2 ) | +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV ) | +-- Attribute ( Key Length = 128 ) | +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV ) | +-- Attribute ( Key Length = 256 ) | +-- Transform ESN ( Name = ESNs ) +-- Transform ESN ( Name = No ESNs )

Ogni struttura proposta/protocollo è seguita da una o più strutture di trasformazione. Il numero di trasformazioni distinte è generalmente determinato dal protocollo. AH ne ha generalmente due: il numero di sequenza esteso (ESN) e un algoritmo di verifica di integrità. ESP ne ha generalmente tre: ESN, un algoritmo di cifratura e un algoritmo di verifica di integrità. IKE ne ha generalmente quattro: un gruppo Diffie-Hellman, un algoritmo di verifica di integrità, un algoritmo PRF e un algoritmo di cifratura. Per ciascun protocollo, l'insieme delle trasformazioni consentite riceve numeri Transform ID, che appaiono nell'intestazione di ciascuna trasformazione.

Se vi sono più trasformazioni dello stesso tipo di trasformazione, la proposta è un « OR » (OR) tra tali trasformazioni. Se vi sono più trasformazioni di tipi diversi, la proposta è un « AND » (AND) tra i diversi gruppi. Ad esempio, per proporre ESP associato a (3DES o AES-CBC) e (HMAC_MD5 o HMAC_SHA), la proposta ESP includerà due candidati di tipo di trasformazione 1 (uno per 3DES, uno per AEC-CBC) nonché due candidati di tipo di trasformazione 3 (uno per HMAC_MD5, uno per HMAC_SHA). Ciò propone effettivamente quattro combinazioni di algoritmi. Se l'iniziatore desidera proporre solo un sottoinsieme di queste combinazioni, ad esempio (3DES e HMAC_MD5) o (IDEA e HMAC_SHA), ciò non può essere codificato come più trasformazioni all'interno di un'unica proposta. Invece, l'iniziatore DEVE costruire due proposte distinte, ciascuna contenente due trasformazioni.

Una data trasformazione PUÒ avere uno o più attributi. Gli attributi sono necessari quando una trasformazione può essere usata in più modi (ad esempio un algoritmo di cifratura a lunghezza di chiave variabile). La trasformazione specifica l'algoritmo, l'attributo specifica la lunghezza della chiave. La maggior parte delle trasformazioni non ha attributi. Una trasformazione NON DEVE avere più attributi dello stesso tipo. Per proporre valori alternativi per un attributo (ad esempio più lunghezze di chiave per l'algoritmo di cifratura AES), l'implementazione DEVE includere più trasformazioni dello stesso tipo, ciascuna con un attributo separato.

Si noti che la semantica di trasformazioni e attributi differisce fortemente da quella di IKEv1. In IKEv1, una singola trasformazione trasportava più algoritmi per un protocollo, uno trasportato nella trasformazione e i restanti negli attributi.

                 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 6:  Formato del payload SA

o Proposals (lunghezza variabile) – una o più sotto-strutture di proposta.

Il tipo di payload del payload SA è trentatré (33).

3.3.1. Sotto-struttura di proposta

                 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (last) or 2 | RESERVED | Proposal Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Proposal Num | Protocol ID | SPI Size |Num Transforms| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SPI (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 7:  Sotto-struttura di proposta

o 0 (ultimo) o 2 (altro) (1 byte) – indica se questa è l'ultima sotto-struttura di proposta nella SA. Questa sintassi è ereditata da ISAKMP, ma non è necessaria poiché l'ultima proposta è identificabile dalla lunghezza della SA. Il valore (2) corrisponde al tipo di payload della proposta in IKEv1, e i primi quattro byte della struttura di proposta sono stati progettati per assomigliare all'intestazione di un payload.

o RESERVED (1 byte) – DEVE essere inviato come 0; DEVE essere ignorato alla ricezione.

o Proposal Length (2 byte, intero senza segno) – la lunghezza di questa proposta, inclusi tutte le trasformazioni e gli attributi che la seguono.

o Proposal Num (1 byte) – quando si propone una proposta, la prima proposta nel payload SA DEVE essere 1 e le proposte successive DEVONO essere superiori di 1 alla proposta precedente (ciò esprime una relazione « OR » tra due proposte). Quando una proposta è accettata, il numero di proposta nel payload SA DEVE corrispondere al numero della proposta accettata così come inviata.

o Protocol ID (1 byte) – indica l'identificativo di protocollo IPsec in negoziazione. I valori nella tabella seguente erano validi solo alla data di pubblicazione di RFC 4306. Da allora possono essere stati aggiunti o potranno essere aggiunti altri valori. I lettori devono consultare [IKEV2IANA] per i valori più recenti.

Protocol Protocol ID

IKE 1 AH 2 ESP 3

o SPI Size (1 byte) – per la negoziazione iniziale della SA IKE, questo campo DEVE essere 0; la SPI è ottenuta dall'intestazione esterna. Durante le negoziazioni successive, è pari alla dimensione della SPI (in byte) del protocollo corrispondente (IKE: 8, ESP e AH: 4).

o Num Transforms (1 byte) – indica il numero di trasformazioni in questa proposta.

o SPI (lunghezza variabile) – la SPI dell'entità trasmittente. Anche se il campo SPI Size non è un multiplo intero di 4 byte, non viene applicato alcun riempimento al payload. Quando il campo SPI Size è 0, questo campo non appare nel payload Security Association.

o Transforms (lunghezza variabile) – una o più sotto-strutture di trasformazione.

3.3.2. Sotto-struttura di trasformazione

                 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (last) or 3 | RESERVED | Transform Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Transform Type | RESERVED | Transform ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Transform Attributes ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 8:  Sotto-struttura di trasformazione

o 0 (ultimo) o 3 (altro) (1 byte) – indica se questa è l'ultima sotto-struttura di trasformazione nella proposta. Questa sintassi è ereditata da ISAKMP, ma non è necessaria poiché l'ultima trasformazione è identificabile dalla lunghezza della proposta. Il valore (3) corrisponde al tipo di payload della trasformazione in IKEv1, e i primi quattro byte della struttura di trasformazione sono stati progettati per assomigliare all'intestazione di un payload.

o RESERVED – DEVE essere inviato come 0; DEVE essere ignorato alla ricezione.

o Transform Length – la lunghezza della sotto-struttura di trasformazione (in byte), inclusi intestazione e attributi.

o Transform Type (1 byte) – il tipo di trasformazione specificato nella proposta. I diversi protocolli supportano diversi tipi di trasformazione. Per alcuni protocolli, alcune trasformazioni possono essere opzionali. Se una trasformazione è opzionale e l'iniziatore desidera proporre di ometterla, non include alcuna trasformazione di quel tipo nella proposta. Se l'iniziatore desidera che la trasformazione sia opzionale per il risponditore, include una sotto-struttura di trasformazione in cui una delle opzioni è Transform ID = 0.

o Transform ID (2 byte) – l'istanza specifica del tipo di trasformazione proposto.

I valori del tipo di trasformazione sono riportati nella tabella seguente. I valori nella tabella seguente erano validi solo alla data di pubblicazione di RFC 4306. Da allora possono essere stati aggiunti o potranno essere aggiunti altri valori. I lettori devono consultare [IKEV2IANA] per i valori più recenti.

Description Trans. Used In Type

Encryption Algorithm (ENCR) 1 IKE and ESP Pseudorandom Function (PRF) 2 IKE Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP Diffie-Hellman group (D-H) 4 IKE, optional in AH & ESP Extended Sequence Numbers (ESN) 5 AH and ESP

(*) Per quanto riguarda il formato del payload di cifratura definito in questo documento, la negoziazione di un algoritmo di integrità è obbligatoria. Ad esempio, [AEAD] definisce un formato aggiuntivo basato sulla crittografia autenticata (authenticated encryption), in cui non viene negoziato alcun algoritmo di integrità separato.

Per il tipo di trasformazione 1 (algoritmo di cifratura), la Transform ID è riportata nella tabella seguente. I valori nella tabella seguente erano validi solo alla data di pubblicazione di RFC 4306. Da allora possono essere stati aggiunti o potranno essere aggiunti altri valori. I lettori devono consultare [IKEV2IANA] per i valori più recenti.

Name Number Defined In

ENCR_DES_IV64 1 (UNSPECIFIED) ENCR_DES 2 (RFC2405), [DES] ENCR_3DES 3 (RFC2451) ENCR_RC5 4 (RFC2451) ENCR_IDEA 5 (RFC2451), [IDEA] ENCR_CAST 6 (RFC2451) ENCR_BLOWFISH 7 (RFC2451) ENCR_3IDEA 8 (UNSPECIFIED) ENCR_DES_IV32 9 (UNSPECIFIED) ENCR_NULL 11 (RFC2410) ENCR_AES_CBC 12 (RFC3602) ENCR_AES_CTR 13 (RFC3686)

Per il tipo di trasformazione 2 (funzione pseudo-casuale), la Transform ID è riportata nella tabella seguente. I valori nella tabella seguente erano validi solo alla data di pubblicazione di RFC 4306. Da allora possono essere stati aggiunti o potranno essere aggiunti altri valori. I lettori devono consultare [IKEV2IANA] per i valori più recenti.

Name Number Defined In

PRF_HMAC_MD5 1 (RFC2104), [MD5] PRF_HMAC_SHA1 2 (RFC2104), [SHA] PRF_HMAC_TIGER 3 (UNSPECIFIED)

Per il tipo di trasformazione 3 (algoritmo di integrità), le Transform ID definite sono riportate nella tabella seguente. I valori nella tabella seguente erano validi solo alla data di pubblicazione di RFC 4306. Da allora possono essere stati aggiunti o potranno essere aggiunti altri valori. I lettori devono consultare [IKEV2IANA] per i valori più recenti.

Name Number Defined In

NONE 0 AUTH_HMAC_MD5_96 1 (RFC2403) AUTH_HMAC_SHA1_96 2 (RFC2404) AUTH_DES_MAC 3 (UNSPECIFIED) AUTH_KPDK_MD5 4 (UNSPECIFIED) AUTH_AES_XCBC_96 5 (RFC3566)

Per il tipo di trasformazione 4 (gruppo Diffie-Hellman), le Transform ID definite sono riportate nella tabella seguente. I valori nella tabella seguente erano validi solo alla data di pubblicazione di RFC 4306. Da allora possono essere stati aggiunti o potranno essere aggiunti altri valori. I lettori devono consultare [IKEV2IANA] per i valori più recenti.

Name Number Defined In

NONE 0 768-bit MODP 1 Appendix B 1024-bit MODP 2 Appendix B 1536-bit MODP 5 [ADDGROUP] 2048-bit MODP 14 [ADDGROUP] 3072-bit MODP 15 [ADDGROUP] 4096-bit MODP 16 [ADDGROUP] 6144-bit MODP 17 [ADDGROUP] 8192-bit MODP 18 [ADDGROUP]

Sebbene ESP e AH non contengano direttamente uno scambio Diffie-Hellman, un gruppo Diffie-Hellman PUÒ essere negoziato per una Child SA. Ciò consente al peer di usare Diffie-Hellman in uno scambio CREATE_CHILD_SA per fornire segretezza inoltrata perfetta (perfect forward secrecy) per le chiavi della Child SA generate.

Per il tipo di trasformazione 5 (numeri di sequenza estesi), le Transform ID definite sono riportate nella tabella seguente. I valori nella tabella seguente erano validi solo alla data di pubblicazione di RFC 4306. Da allora possono essere stati aggiunti o potranno essere aggiunti altri valori. I lettori devono consultare [IKEV2IANA] per i valori più recenti.

Name Number

No Extended Sequence Numbers 0 Extended Sequence Numbers 1

Si noti che un iniziatore che supporta ESN include generalmente due trasformazioni ESN nella sua proposta, con valori « 0 » e « 1 ». Una proposta che contiene una singola trasformazione ESN di valore « 1 » significa che l'uso di numeri di sequenza normali (non estesi) non è accettabile.

Dalla pubblicazione di RFC 4306 sono stati definiti numerosi tipi di trasformazione aggiuntivi. Per i dettagli, vedere il registro IANA IKEv2.

3.3.3. Tipi di trasformazione validi per protocollo

Il numero e il tipo di trasformazioni che accompagnano un payload SA dipendono dal protocollo in cui la SA stessa si trova. Una proposta che stabilisce una SA ha i seguenti tipi di trasformazione obbligatori e opzionali. Un'implementazione conforme DEVE comprendere tutti i tipi obbligatori e opzionali per ciascun protocollo che supporta (sebbene non sia tenuta ad accettare una proposta contenente un insieme inaccettabile). Se l'unico valore che accetterebbe per un tipo opzionale è NONE, la proposta PUÒ omettere tale tipo opzionale.

Protocol Mandatory Types Optional Types

IKE ENCR, PRF, INTEG*, D-H ESP ENCR, ESN INTEG, D-H AH INTEG, ESN D-H

(*) Per quanto riguarda il formato del payload di cifratura definito in questo documento, la negoziazione di un algoritmo di integrità è obbligatoria. Ad esempio, [AEAD] definisce un formato aggiuntivo basato sulla crittografia autenticata, in cui non viene negoziato alcun algoritmo di integrità separato.

3.3.4. Transform ID obbligatorie

Le suite che in questo documento DOVEVANO e DOVREBBERO essere supportate per l'interoperabilità sono state rimosse poiché potrebbero cambiare più velocemente di quanto evolva questo documento. Al momento della pubblicazione del presente documento, [RFC4307] definisce tali suite; si noti tuttavia che esso potrebbe essere aggiornato in futuro e che altri RFC potrebbero definire insiemi di suite diversi.

Una lezione importante appresa da IKEv1 è la seguente: nessun sistema dovrebbe implementare solo gli algoritmi obbligatori e aspettarsi che siano la scelta migliore per tutti i clienti.

È molto probabile che IANA aggiunga in futuro trasformazioni supplementari e che alcuni utenti desiderino usare suite private, in particolare per IKE; le implementazioni DOVREBBERO essere in grado di supportare parametri diversi fino a un limite di dimensione specificato. Per sostenere questo obiettivo, tutte le implementazioni IKEv2 DOVREBBERO includere una funzione di amministrazione che consenta (all'utente o all'amministratore di sistema) di specificare i parametri Diffie-Hellman (generatore, modulo nonché lunghezza e valore dell'esponente) per un nuovo gruppo Diffie-Hellman. Le implementazioni DOVREBBERO fornire un'interfaccia di amministrazione tramite la quale possano essere inseriti tali parametri insieme alla Transform ID associata, per abilitare la negoziazione di tali gruppi.

Tutte le implementazioni IKEv2 DEVONO includere una funzione di amministrazione che consenta all'utente o all'amministratore di sistema di specificare le suite accettabili da utilizzare con IKE. Alla ricezione di un payload contenente un insieme di Transform ID, l'implementazione DEVE confrontare le Transform ID trasmesse con le Transform ID configurate localmente tramite il controllo di amministrazione, per verificare, secondo la politica locale, che la suite proposta sia accettabile. Le implementazioni DEVONO rifiutare le proposte SA non autorizzate da tali controlli delle suite IKE. Si noti che l'implementazione obbligatoria delle suite di cifratura non implica necessariamente che esse siano configurate come accettabili per la politica locale.

3.3.5. Attributi di trasformazione

Ciascuna trasformazione in un payload Security Association PUÒ contenere attributi che modificano o affinano la specifica della trasformazione. L'insieme di attributi validi dipende dalla trasformazione. Al momento è definito un solo tipo di attributo: l'attributo Key Length (lunghezza della chiave), usato da alcune trasformazioni di cifratura a chiave di lunghezza variabile (vedi sotto).

Gli attributi sono coppie tipo/valore, definite come segue. Un attributo può avere un valore fisso di due byte o un valore di lunghezza variabile. In quest'ultimo caso, l'attributo è codificato come Tipo/Lunghezza/Valore (TLV).

                 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| Attribute Type | AF=0 Attribute Length | |F| | AF=1 Attribute Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AF=0 Attribute Value | | AF=1 Not Transmitted | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 9:  Attributo di dati

o Attribute Format (AF) (1 bit) – indica se l'attributo di dati segue il formato Tipo/Lunghezza/Valore (TLV) o il formato abbreviato Tipo/Valore (TV). Se il bit AF è zero (0), l'attributo usa il formato TLV; se il bit AF è uno (1), è usato il formato TV (con un valore di due byte).

o Attribute Type (15 bit) – un identificativo unico per ciascun tipo di attributo (vedi sotto).

o Attribute Value (lunghezza variabile) – il valore di attributo associato al tipo di attributo. Se il bit AF è zero (0), questo campo ha la lunghezza variabile definita dal campo Attribute Length; se il bit AF è uno (1), la lunghezza del valore di attributo è di 2 byte.

L'unico tipo di attributo attualmente definito (Key Length) è a lunghezza fissa; l'inclusione di una codifica a lunghezza variabile è prevista solo per future estensioni. Gli attributi descritti come a lunghezza fissa NON DEVONO essere codificati a lunghezza variabile, a meno che la loro lunghezza non superi i due byte. Gli attributi a lunghezza variabile NON DEVONO essere codificati a lunghezza fissa, anche se il loro valore rientra in due byte. Nota: ciò differisce da IKEv1, dove la maggiore flessibilità poteva semplificare la scrittura dei messaggi, ma complicava senza dubbio gli analizzatori.

I valori nella tabella seguente erano validi solo alla data di pubblicazione di RFC 4306. Da allora possono essere stati aggiunti o potranno essere aggiunti altri valori. I lettori devono consultare [IKEV2IANA] per i valori più recenti.

Attribute Type Value Attribute Format

Key Length (in bits) 14 TV

I valori 0–13 nonché 15–17 sono stati usati in un contesto simile in IKEv1 e non dovrebbero essere assegnati, salvo per valori corrispondenti.

L'attributo Key Length specifica la lunghezza della chiave in bit (DEVE usare l'ordine dei byte di rete) e si applica ad alcune trasformazioni come segue:

o L'attributo Key Length NON DEVE essere usato per le trasformazioni che usano chiavi a lunghezza fissa. Ciò include ENCR_DES, ENCR_IDEA, nonché tutte le trasformazioni di tipo 2 (funzione pseudo-casuale) e di tipo 3 (algoritmo di integrità) definite in questo documento. Si raccomanda alle future trasformazioni di tipo 2 o 3 di non usare questo attributo.

o Alcune trasformazioni prescrivono che l'attributo Key Length debba essere sempre incluso (l'omissione dell'attributo non è consentita e una proposta che non lo include DEVE essere rifiutata). Ciò include ad esempio ENCR_AES_CBC ed ENCR_AES_CTR.

o Alcune trasformazioni consentono chiavi di lunghezza variabile, ma definiscono una lunghezza di chiave predefinita nel caso in cui l'attributo non sia incluso. Ciò include ad esempio ENCR_RC5 ed ENCR_BLOWFISH.

Nota di implementazione: per migliorare ulteriormente l'interoperabilità e supportare endpoint aggiornati indipendentemente, le implementazioni di questo protocollo DOVREBBERO accettare valori che ritengono offrano una sicurezza superiore. Ad esempio, se il peer è configurato per accettare una chiave di lunghezza X bit per un certo cifrario e gli viene offerta una chiave più lunga per lo stesso cifrario, l'implementazione DOVREBBE accettare la proposta se supporta l'uso di una chiave più lunga.

Il supporto di questa capacità consente al risponditore di esprimere il concetto di un livello di sicurezza « almeno » — « cifrario Y con chiave di almeno X bit ». Tuttavia, poiché l'attributo è sempre restituito così com'è (vedi sezione seguente), un iniziatore che desideri accettare più lunghezze di chiave DEVE includere più trasformazioni dello stesso tipo, ciascuna con un attributo Key Length diverso.

3.3.6. Negoziazione degli attributi

Durante la negoziazione di un'associazione di sicurezza, l'iniziatore sottopone proposte al risponditore. Il risponditore DEVE selezionare un singolo insieme completo di parametri tra le proposte (o rifiutare tutte le proposte se non ve n'è alcuna di accettabile). Se vi sono più proposte, il risponditore DEVE selezionarne una sola. Se la proposta scelta ha più trasformazioni dello stesso tipo, il risponditore DEVE selezionarne una sola. Tutti gli attributi di una trasformazione scelta DEVONO essere restituiti così come sono. L'iniziatore dello scambio DEVE verificare che la proposta accettata sia coerente con una delle sue proposte e, in caso contrario, DEVE interrompere lo scambio.

Se il risponditore riceve una proposta contenente un tipo di trasformazione che non comprende, o una proposta priva del tipo di trasformazione obbligatorio, DEVE considerare la proposta inaccettabile; tuttavia, le altre proposte nello stesso payload SA sono trattate normalmente. Analogamente, se il risponditore riceve una trasformazione che non comprende, o una trasformazione contenente un attributo di trasformazione che non comprende, DEVE considerare la trasformazione inaccettabile; le altre trasformazioni dello stesso tipo sono trattate normalmente. Ciò consente di definire in futuro nuovi tipi di trasformazione e attributi di trasformazione.

La negoziazione del gruppo Diffie-Hellman presenta alcune sfide particolari. La proposta SA contiene nello stesso messaggio gli attributi della proposta e un valore pubblico Diffie-Hellman (KE). Se, nello scambio iniziale, l'iniziatore propone l'uso di uno tra più gruppi Diffie-Hellman, DOVREBBE scegliere quello che il risponditore accetterà molto probabilmente e includere il KE corrispondente. Se il risponditore seleziona una proposta che usa un gruppo Diffie-Hellman diverso (diverso da NONE), indica il gruppo corretto nella sua risposta e l'iniziatore DOVREBBE, ripetendo il primo messaggio, scegliere un elemento di quel gruppo come valore KE. Tuttavia, DOVREBBE continuare a proporre l'intero insieme di gruppi che supporta, per prevenire attacchi di declassamento da parte di un intermediario (man-in-the-middle). Se uno dei gruppi proposti è il gruppo Diffie-Hellman NONE e il risponditore seleziona quel gruppo Diffie-Hellman, DEVE ignorare il payload KE dell'iniziatore e omettere il payload KE dalla sua risposta.