Scambio di chiavi durante la fase IKE_AUTH di IKEv2

Question

Scambio di chiavi durante la fase IKE_AUTH di IKEv2

#1 da (1 voti)

1

Questo è l'aspetto di un casuale handshake IKEv2 :

  Initiator                                                       Responder
  |                                                                      |
 1|-----------------------> HDR, SAi1, KEi, Ni ------------------------->|
 2|<----------------- HDR, SAr1, KEr, Nr, [CERTREQ] <--------------------|
 3|----> HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr}-->| 
 4|<------------ HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr} <-----------|
  |                                                                      |

Dove i messaggi (1) e (2) appartengono allo scambio IKE_SA_INIT e i messaggi (3) e (4) appartengono allo scambio IKE_AUTH . Ho analizzato una traccia wirehark di questo scambio e mi sembra che durante IKE_AUTH (SAi2, SAr2) , l'iniziatore / il risponditore pubblicizzi l'insieme di algoritmi di sicurezza che supporta / sceglie rispettivamente (crittografia, autenticazione, protezione dell'integrità, gruppo diffie-hellman) . Tuttavia nessuno dei due fa pubblicità al suo valore di DH. Quindi non ci sono scambi di chiavi effettivi qui. La mia domanda è per quale scopo serve la negoziazione dell'associazione di sicurezza (SAi2, SAr2) ? e perché abbiamo anche bisogno di avere un secondo scambio di chiavi dal momento che il protocollo ha già raggiunto uno durante IKE_SA_INIT (In altre parole, perché abbiamo bisogno di negoziare nuove chiavi)?

diffie-hellman ipsec ike

posta sasuke_X220 15.07.2017 - 17:35

fonte

1 risposta

Leggi altre domande sui tag diffie-hellman ipsec ike

Come posso collegare un dispositivo USB a una macchina virtuale ignorando l'host? Il negozio di carte di credito prima quattro e le ultime quattro quali SAQ PCI?

score 1 · Accepted Answer

I payload SAi2/SAr2 , insieme ai payload TSi/TSr , vengono utilizzati per negoziare la Child SA iniziale. Come per RFC 7296, sezione 1.2 :

The initiator begins negotiation of a Child SA using the SAi2 payload. The final fields (starting with SAi2) are described in the description of the CREATE_CHILD_SA exchange.

Tuttavia, il materiale chiave per questa Child SA è derivato dal materiale della chiave IKE (stabilito con il KE di payload durante IKE_SA_INIT ), quindi non esiste uno scambio di chiavi separato. I gruppi DH non sono esplicitamente inclusi nei% payload SA durante IKE_AUTH . Dalla stessa sezione come sopra:

Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads. Thus, the SA payloads in the IKE_AUTH exchange cannot contain Transform Type 4 (Diffie-Hellman group) with any value other than NONE. Implementations SHOULD omit the whole transform substructure instead of sending value NONE.

Un'implementazione IKEv2 che supporta RFC 6023 (Iniziazione IKEv2 senza figli) può omettere questi payload SA/TS e creare un IKE SA senza Child SA iniziale.

Quando si creano o si riprogrammano le Child Child in un secondo momento con scambi CREATE_CHILD_SA , i peer possono negoziare opzionalmente un gruppo DH e scambiare i loro fattori DH pubblici usando KE payloads (se ciò non viene fatto, le chiavi per la nuova Child SA derivano nuovamente da il materiale chiave IKE SA). Questo serve allo scopo di separare l'IKE dalle chiavi Child SA e le chiavi Child SA l'una dall'altra (di solito si parla di Perfect Forward Secrecy o PFS).