IPSec: utilizzo di ESP dopo AH

Question

IPSec: utilizzo di ESP dopo AH

#1 da (3 voti)

3

Se ricordo che applicare correttamente l'ESP dopo AH non è fattibile (usando la modalità di trasporto), ma non riesco a trovare una risposta definitiva perché. Presumo che abbia qualcosa a che fare con ESP che ha un impatto sull'intestazione IP, ma l'unico campo - presumo - che viene modificato è il campo "proto" (AH - > ESP), che non so se AH autentica . Sto parlando della seguente configurazione:

[IPHDR] [Payload]
Applica AH --- > [IPHDR] [AH-H] [Payload]
Applica ESP --- > [Iphdr] [ESP-H] [AH] [Payload] [ESP-Trail] [ESP-Auth]

ip ipsec

posta Actaeonis 24.01.2017 - 23:33

fonte

1 risposta

Leggi altre domande sui tag ip ipsec

impedisce ai virus di modificare i file eseguibili comunemente eseguiti? C'è un modo per rilevare i payload generati dal framework dei veli

score 3 · Accepted Answer

Da un punto di vista tecnico e teorico non c'è nulla che ti impedisca di applicare l'ESP dopo AH in modalità di trasporto. Il campo proto viene ripristinato di nuovo quando viene rimosso ESP. Quindi, a meno che altre parti dell'intestazione IP protette da AH siano state modificate lungo il percorso (ad esempio l'IP di origine a causa di un NAT), questo dovrebbe funzionare correttamente.

Ma dal momento che AH è usato per proteggere l'integrità dei dati trasmessi, di solito vuoi farlo durare. E se utilizzi ESP con crittografia e autenticazione, faresti questo lavoro due volte. Pertanto, RFC 2401 conteneva il seguente testo (non fa più parte di RFC 4301 perché SA è stato rimosso ):

For transport mode SAs, only one ordering of security protocols seems appropriate. AH is applied to both the upper layer protocols and (parts of) the IP header. Thus if AH is used in a transport mode, in conjunction with ESP, AH SHOULD appear as the first header after IP, prior to the appearance of ESP. In that context, AH is applied to the ciphertext output of ESP. In contrast, for tunnel mode SAs, one can imagine uses for various orderings of AH and ESP.

Inoltre, l'esecuzione dell'autenticazione prima della crittografia (ad esempio se si utilizza AH in ESP riservato alla riservatezza) potrebbe non fornire la stessa protezione rispetto al contrario. Come RFC 4303 lo mette nella sua introduzione:

Using encryption without a strong integrity mechanism on top of it (either in ESP or separately via AH) may render the confidentiality service insecure against some forms of active attacks. Moreover, an underlying integrity service, such as AH, applied before encryption does not necessarily protect the encryption-only confidentiality against active attackers [Kra01].

Dove [Kra01] si riferisce al documento "L'ordine di crittografia e autenticazione per la protezione delle comunicazioni (O: quanto è sicuro SSL?)" di Hugo Krawczyk, che sostiene che in determinate circostanze un attaccante attivo potrebbe essere in grado di rompere il crittografia nello schema integrity-before-encryption.