The Cable GuyAuthenticated Internet Protocol

Joseph Davies

Parti di questo articolo illustrano una versione provvisoria di Windows Server 2008. Tali informazioni potrebbero essere soggette a modifiche.

Windows Vista e Windows Server 2008 (attualmente in fase di beta test) supportano entrambi Authenticated Internet Protocol (AuthIP), una versione avanzata del protocollo IKE (Internet Key Exchange). Sia AuthIP che IKE sono protocolli utilizzati per determinare il materiale principale e negoziare i parametri di protezione per comunicazioni protette tramite

Internet Protocol security (IPsec). AuthIP fornisce manutenzione e configurazione semplificate dei criteri IPsec in molte configurazioni e offre flessibilità aggiuntiva per l'autenticazione del peer IPsec. In questo articolo vengono forniti i dettagli sul protocollo AuthIP e descritte le funzionalità di coesistenza tra i peer IPsec che supportano AuthIP e IKE o solo IKE.

Panoramica su IKE

Esempi di negoziazione

Per dimostrare la funzionalità di coesistenza, verrà esaminato cosa succede tra i peer IPsec basati su Windows Vista e su Windows XP quando si tenta di negoziare la protezione di IPsec.

Esempio 1: due peer IPsec basati su Windows Vista in modalità di richiesta

In questo esempio, l'iniziatore è un peer IPsec basato su Windows Vista (Peer 1) e il risponditore sta eseguendo Windows Vista (Peer 2). Entrambi i peer sono configurati con modalità di richiesta sia per le comunicazioni in ingresso che per quelle in uscita. In modalità di richiesta, un peer IPsec richiede la protezione di IPsec, che tuttavia non è obbligatoria. Vengono di seguito riportati i messaggi scambiati tra i due peer:

1. Peer 1 invia un segmento SYN (synchronize) TCP in testo normale iniziando una connessione TCP con Peer 2.
2. Peer 2 invia un segmento SYN-ACK (acknowledgment) TCP.
3. Peer 1 invia un segmento ACK TCP.
4. Peer 1 invia un messaggio ISAKMP basato su AuthIP iniziando la negoziazione in modalità principale AuthIP.
5. Peer 1 invia un messaggio ISAKMP basato su IKE iniziando la negoziazione in modalità principale IKE.
6. Peer 2 risponde con un messaggio ISAKMP basato su AuthIP continuando la negoziazione in modalità principale AuthIP.
7. Peer 1 e Peer 2 completano la negoziazione in modalità principale, modalità veloce e modalità estesa (facoltativo) di AuthIP.
8. I segmenti successivi inviati tramite la connessione TCP sono protetti con IPsec.

L'esatto ordine dei messaggi numerati da 1 a 5 dipende dalla latenza di rete. Gli esempi descritti in questo articolo valgono per una rete a latenza molto ridotta, in cui l'handshake TCP (Messaggi da 1 a 3) termina prima che Peer 1 possa inviare i messaggi ISAKMP iniziali (Messaggi 4 e 5). Su una rete a latenza superiore, Peer 1 invierebbe il segmento SYN TCP in testo normale, il messaggio ISAKMP basato su AuthIP e quindi il messaggio ISAKMP basato su IKE come primi tre messaggi dello scambio.

Esempio 2: peer IPsec basato su Windows Vista in modalità di richiesta e peer IPsec basato su Windows XP in modalità di richiesta

In questo esempio, l'iniziatore è un peer IPsec basato su Windows Vista (Peer 1) e il risponditore sta eseguendo Windows XP (Peer 2). Entrambi i peer sono configurati con modalità di richiesta sia per le comunicazioni in ingresso che per quelle in uscita. Vengono di seguito riportati i messaggi scambiati tra i due peer:

1. Peer 1 invia un segmento SYN TCP in testo normale iniziando una connessione TCP con Peer 2.
2. Peer 2 invia un segmento SYN-ACK TCP.
3. Peer 1 invia un segmento ACK TCP.
4. Peer 1 invia un messaggio ISAKMP basato su AuthIP iniziando la negoziazione in modalità principale AuthIP.
5. Peer 1 invia un messaggio ISAKMP basato su IKE iniziando la negoziazione in modalità principale IKE.
6. Peer 2 risponde con un messaggio ISAKMP basato su IKE continuando la negoziazione in modalità principale IKE.
7. Peer 1 e Peer 2 terminano la negoziazione in modalità veloce e in modalità principale IKE.
8. I segmenti successivi inviati tramite la connessione TCP sono protetti con IPsec.

Esempio 3: peer IPsec basato su Windows Vista in modalità di richiesta e peer IPsec basato su Windows XP in modalità di richiesta obbligatoria

In questo esempio, l'iniziatore è un peer IPsec basato su Windows Vista (Peer 1) e il risponditore sta eseguendo Windows XP (Peer 2). Peer 1 è configurato con la modalità di richiesta per le comunicazioni in uscita e Peer 2 è configurato con la modalità di richiesta obbligatoria per le comunicazioni in ingresso. In modalità di richiesta obbligatoria, un peer IPsec richiede necessariamente la protezione IPsec ed elimina automaticamente i pacchetti non protetti. Vengono di seguito riportati i messaggi scambiati tra i due peer:

1. Peer 1 invia un segmento SYN TCP in testo normale iniziando una connessione TCP che Peer 2 elimina automaticamente.
2. Peer 1 invia un messaggio ISAKMP basato su AuthIP iniziando una negoziazione in modalità principale AuthIP che Peer 2 elimina automaticamente.
3. Peer 1 invia un messaggio ISAKMP basato su IKE iniziando la negoziazione in modalità principale IKE.
4. Peer 2 risponde con un messaggio ISAKMP basato su IKE continuando la negoziazione in modalità principale IKE.
5. Peer 1 e Peer 2 terminano la negoziazione in modalità veloce e in modalità principale IKE.
6. Peer 1 ritrasmette il segmento SYN TCP (protetto con IPsec).
7. Peer 2 invia il segmento SYN-ACK TCP (protetto con IPsec).
8. Peer 1 invia il segmento ACK TCP (protetto con IPsec).

IKE è uno standard Internet, definito in RFC 2409 (ietf.org/rfc/rfc2409.txt), che definisce un meccanismo per stabilire le associazioni di protezione (SA) IPsec. Una SA è una combinazione di criteri e chiavi compatibili che definiscono i meccanismi e i servizi di protezione che consentono di proteggere la comunicazione tra i peer IPsec. Nello specifico, IKE combina Internet Security Association e Key Management Protocol (ISAKMP) in RFC 2408 e il protocollo di determinazione di chiavi Oakley (RFC 2412). IKE utilizza il protocollo di determinazione di chiavi Oakley per generare materiale chiave segreto per comunicazioni protette.

IKE utilizza ISAKMP per negoziare le SA. ISAKMP comprende funzionalità per identificare e autenticare i peer, gestire le SA e scambiare materiale chiave. ISAKMP è un framework per la negoziazione di comunicazioni protette indipendente dai protocolli di scambio chiavi specifici, dagli algoritmi di integrità e crittografia e dai metodi di autenticazione.

I peer IPsec utilizzano IKE per eseguire la negoziazione in modalità veloce e modalità principale. La negoziazione in modalità principale crea la SA ISAKMP che protegge le negoziazioni della protezione. Durante la negoziazione in modalità principale, l'iniziatore e il risponditore si scambiano una serie di messaggi ISAKMP per negoziare gli algoritmi di hash e di crittografia per la SA ISAKMP, scambiare materiale di determinazione chiavi e identificarsi e autenticarsi a vicenda.

Durante la fase di negoziazione in modalità veloce, vengono create le due SA IPsec (una per i dati in ingresso e un'altra per i dati in uscita) che proteggono i dati inviati tra due peer IPsec. Durante la negoziazione in modalità veloce, l'iniziatore e il risponditore si scambiano una serie di messaggi ISAKMP crittografati per negoziare gli algoritmi di hash e di crittografia sia per le SA IPsec in entrata che per quelle in uscita.

Per ulteriori informazioni sulla negoziazione in modalità veloce e in modalità principale basata su IKE, vedere "Negoziazione IKE per le associazioni di protezione IPsec" all'indirizzo microsoft.com/technet/community/columns/cableguy/cg0602.mspx.

Panoramica su AuthIP

AuthIP è una versione migliorata di IKE che offre maggiore flessibilità supportando l'autenticazione per utente, l'autenticazione con più credenziali, la negoziazione con metodo di autenticazione migliorato e l'autenticazione asimmetrica. Allo stesso modo di IKE, AuthIP supporta la negoziazione in modalità principale e in modalità veloce. AuthIP supporta inoltre la modalità estesa, una parte della negoziazione del peer IPsec durante la quale può essere eseguita una seconda fase di autenticazione. La modalità estesa, facoltativa, può essere utilizzata per più autenticazioni. Ad esempio, con la modalità estesa è possibile eseguire autenticazioni separate basate sull'utente e basate sul computer.

Il supporto per l'autenticazione multipla fa parte dell'applicazione di IPsec per la piattaforma Protezione accesso alla rete, in cui i peer IPsec eseguono l'autenticazione con le credenziali del computer e utilizzano anche un certificato di integrità per dimostrare di essere conformi ai requisiti di integrità del sistema. Per ulteriori informazioni sulla Protezione accesso alla rete, vedere microsoft.com/nap. Per ulteriori informazioni sulle funzionalità di AuthIP, vedere l'articolo "AuthIP in Windows Vista" all'indirizzo microsoft.com/technet/community/columns/cableguy/cg0806.mspx.

Messaggi di AuthIP

Sia IKE che AuthIP utilizzano ISAKMP come protocollo di negoziazione SA e di scambio chiavi. I messaggi ISAKMP vengono inviati tramite il protocollo UDP (User Datagram Protocol) e consistono in un'intestazione ISAKMP e uno o più payload ISAKMP. L'intestazione ISAKMP contiene le informazioni sul messaggio, tra cui il tipo di messaggio. Nella Figura 1 viene illustrato il formato dell'intestazione ISAKMP.

Figura 1** Formato dell'intestazione ISAKMP **

Nell'intestazione ISAKMP, i campi Cookie iniziatore e Cookie risponditore sono impostati su un numero a caso diverso da zero selezionato dai peer IPsec. Il campo Payload successivo indica il primo payload nel messaggio ISAKMP, immediatamente dopo l'intestazione ISAKMP. RFC 2408 elenca i valori definiti nel campo Payload successivo. I tipi di payload 128-255 sono riservati ad uso privato. I campi Versione principale e Versione secondaria indicano le versioni di ISAKMP sul peer IPsec che invia il messaggio ISAKMP. Per IKE e AuthIP, la versione principale è 1 e la versione secondaria è 0.

Il campo Tipo di scambio indica il tipo di scambio di ISAKMP eseguito. Il tipo di scambio detta la struttura e l'ordine dei payload ISAKMP. RFC 2408 definisce i valori del campo Tipo di scambio. I tipi di scambio 128-255 sono riservati ad uso privato.

Il campo Flag contiene tre flag definiti nella specifica RFC 2408. Il bit inferiore (bit 0) è il bit Encryption, che indica che i payload ISAKMP sono crittografati (quando impostato su 1) o non crittografati (quando impostato su 0). La crittografia viene effettuata utilizzando l'algoritmo negoziato per la SA ISAKMP, che viene identificato dalla combinazione dei campi Cookie iniziatore e Cookie risponditore. Il bit di basso livello successivo (Bit 1) è il bit Commit, che indica se lo scambio di chiavi è sincronizzato (quando impostato su 1) o non sincronizzato (quando impostato su 0). Il bit Commit viene utilizzato per assicurare che la SA completi la negoziazione prima che vengano inviati i dati crittografati. Il bit di basso livello successivo (Bit 2) è il bit Authentication Only, utilizzato per indicare che il messaggio contiene (quando impostato su 1) o non contiene (quando impostato su 0) l'intero payload Notify del tipo di scambio informativo ed è stato autenticato, ma non crittografato.

Il campo ID messaggio contiene un identificatore univoco per il messaggio. Questo campo viene utilizzato per impedire conflitti quando entrambi i peer IPsec tentano di stabilire contemporaneamente una SA IPsec. Il campo Lunghezza indica la lunghezza dell'intero messaggio ISAKMP.

Per IKE, il messaggio ISAKMP contiene una serie di payload ISAKMP. Il primo payload è indicato dal campo Payload successivo dell'intestazione ISAKMP. Ogni payload ISAKMP dispone del proprio campo Payload successivo per indicare il payload successivo. Il campo Payload successivo dell'ultimo payload è impostato su 0. Nella Figura 2 viene mostrato il formato dei messaggi IKE.

Figura 2** Formato dei messaggi IKE **

AuthIP utilizza i messaggi ISAKMP con i tipi di scambio 243 (Modalità principale), 244 (Modalità veloce), 245 (Modalità estesa) e 246 (Notifica) nel campo Tipo di scambio dell'intestazione ISAKMP. Un'importante differenza che contraddistingue i messaggi ISAKMP basati su AuthIP consiste nel fatto che contengono esclusivamente un payload ISAKMP: il payload Crypto o il payload Notify. Il payload Crypto contiene i payload incorporati utilizzati per la negoziazione in modalità principale, modalità veloce o modalità estesa. Il payload Crypto può contenere un insieme di payload crittografati o in testo normale, in base al bit Encryption nel campo Flag dell'intestazione ISAKMP. Nella Figura 3 viene mostrato il formato dei messaggi AuthIP contenenti il payload Crypto.

Figura 3** Formato dei messaggi AuthIP contenenti il payload Crypto **

Coesistenza di AuthIP e IKE

Windows Vista® e Windows Server® 2008 supportano sia IKE che AuthIP. Windows® XP e Windows Server 2003, invece, supportano solo IKE. Un peer IPsec iniziatore che supporta sia AuthIP che IKE e dispone di un criterio di protezione della connessione che utilizza sia AuthIP che IKE deve stabilire se il peer IPsec risponditore supporta AuthIP o IKE. Di conseguenza, deve utilizzare il protocollo più appropriato per la negoziazione della protezione di IPsec, dando priorità all'utilizzo di AuthIP piuttosto che di IKE.

Per determinare il protocollo di negoziazione del peer IPsec risponditore, un peer IPsec iniziatore che utilizza sia AuthIP che IKE invia contemporaneamente i seguenti messaggi:

• Messaggio 1: un messaggio AuthIP che inizia la negoziazione in modalità principale
• Messaggio 2: un messaggio IKE che inizia la negoziazione in modalità principale

Se il nodo che risponde supporta AuthIP, deve rispondere al Messaggio 1 con un messaggio AuthIP continuando la negoziazione in modalità principale ed eliminando automaticamente il Messaggio 2. Un nodo che risponde ma non supporta AuthIP elimina automaticamente il Messaggio 1 perché il campo Tipo di scambio contiene un valore non supportato e risponde al Messaggio 2.

Per impedire la negoziazione basata su IKE tra due peer IPsec che eseguono Windows Vista o Windows Server 2008 quando il Messaggio 1 proviene dalla rete o arriva dopo il Messaggio 2, i peer IPsec che eseguono Windows Vista o Windows Server 2008 inviano il Messaggio 2 con un payload ISAKMP di ID del fornitore supportato da AuthIP. Il payload di ID del fornitore supportato da AuthIP indica che il peer IPsec supporta AuthIP.

Quindi, se un peer IPsec che esegue Windows Vista o Windows Server 2008 riceve il Messaggio 2 con il payload di ID del fornitore supportato da AuthIP, attende che il peer IPsec iniziatore ritrasmetta il Messaggio 1 e il Messaggio 2 e risponde al Messaggio 1.

Il peer IPsec iniziatore continua a ritrasmettere sia il Messaggio 1 che il Messaggio 2 fino a quando non riceve una risposta o non scade il tempo. Quando l'iniziatore riceve una risposta, determina la capacità del risponditore dall'intestazione ISAKMP della risposta. Se il campo Tipo di scambio è impostato su 243 (il tipo di scambio per la negoziazione in modalità principale basata su AuthIP), il risponditore consente AuthIP. Se il campo Tipo di scambio è impostato su 2 (il tipo di scambio per la negoziazione in modalità principale basata su IKE e la protezione dell'identità), il risponditore consente IKE.

In base alla risposta, l'iniziatore risponde con il messaggio AuthIP successivo per la negoziazione in modalità principale AuthIP o con il messaggio IKE successivo per la negoziazione in modalità principale IKE. I peer IPsec devono utilizzare lo stesso protocollo che è stato utilizzato per negoziare la SA ISAKMP per tutta la durata della stessa.

Joseph Daviesè un technical writer di Microsoft e autore della rubrica mensile in linea The Cable Guy di TechNet, disponibile all'indirizzo Microsoft.com/technet/community/columns/cableguy.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.