Le petit câbleurAuthenticated Internet Protocol

Joseph Davy

Certaines parties de cet article font référence à une version préliminaire de Windows Server 2008. Ces informations sont susceptibles d'être modifiées.

Windows Vista et Windows Server 2008 (maintenant en phase de test de version Bêta) prennent tous deux en charge le protocole AuthIP (Authenticated Internet Protocol), une version améliorée du protocole IKE (Internet Key Exchange). AuthIP et IKE sont tous deux des protocoles utilisés pour déterminer le matériel de génération de clé et négocier les paramètres de sécurité pour les communications protégées utilisant

la sécurité du protocole Internet (IPsec). AuthIP propose une configuration et une maintenance de stratégie IPSec simplifiées dans de nombreuses configurations et offre une flexibilité supplémentaire pour l'authentification d'homologue IPSec. Cet article décrit les détails du protocole AuthIP et les comportements de coexistence entre homologues IPSec prenant en charge AuthIP et IKE, ou seulement IKE.

Aperçu général d'IKE

Exemples de négociation

Pour démontrer le comportement de coexistence, examinons ce qui se passe entre les homologues IPSec basés sur Windows Vista et Windows XP lors d'une tentative de négociation de protection IPSec.

Exemple 1 : Deux homologues IPSec basés sur Windows Vista en mode de requête

Dans cet exemple, un homologue IPSec basé sur Windows Vista (Homologue 1) est l'initiateur et le répondeur exécute Windows Vista (Homologue 2). Les deux homologues sont configurés en mode de requête pour les communications entrantes comme sortantes. En mode de requête, un homologue IPSec demande la protection IPSec mais ne la requiert pas. Les messages échangés sont les suivants :

1. Homologue 1 envoie un segment TCP de synchronisation (SYN) en texte clair, établissant une connexion TCP avec Homologue 2.
2. Homologue 2 envoie un segment TCP d'accusé de réception de synchronisation (ACK).
3. Homologue 1 envoie un segment TCP ACK.
4. Homologue 1 envoie un message ISAKMP basé sur AuthIP, établissant une négociation en mode principal AuthIP.
5. Homologue 1 envoie un message ISAKMP basé sur IKE, établissant une négociation en mode principal IKE.
6. Homologue 2 répond par un message ISAKMP basé sur AuthIP, poursuivant la négociation en mode principal AuthIP.
7. Homologue 1 et Homologue 2 terminent la négociation en mode principal, mode rapide et mode étendu (facultatif) AuthIP.
8. Les segments suivants envoyés sur la connexion TCP sont protégés avec IPSec.

L'ordre exact des Messages 1 à 5 dépend de la latence du réseau. Les exemples décrits dans cet article correspondent à un réseau à latence très faible, dans lequel la connexion TCP (Messages 1 à 3) se termine avant qu'Homologue 1 puisse envoyer les messages ISAKMP initiaux (Messages 4 et 5). Sur un réseau à latence plus élevée, Homologue 1 enverrait le segment TCP SYN en texte clair, le message ISAKMP basé sur AuthIP et ensuite le message ISAKMP basé sur IKE comme trois premiers messages de l'échange de messages.

Exemple 2 : Homologue IPsec basé sur Windows Vista en mode de requête et homologue IPSec basé sur Windows XP en mode de requête

Dans cet exemple, un homologue IPSec basé sur Windows Vista (Homologue 1) est l'initiateur et le répondeur exécute Windows XP (Homologue 2). Les deux homologues sont configurés en mode de requête pour les communications entrantes comme sortantes. Les messages échangés sont les suivants :

1. Homologue 1 envoie un segment TCP SYN en texte clair, établissant une connexion TCP avec Homologue 2.
2. Homologue 2 envoie un segment TCP SYN-ACK.
3. Homologue 1 envoie un segment TCP ACK.
4. Homologue 1 envoie un message ISAKMP basé sur AuthIP, établissant une négociation en mode principal AuthIP.
5. Homologue 1 envoie un message ISAKMP basé sur IKE, établissant une négociation en mode principal IKE.
6. Homologue 2 répond par un message ISAKMP basé sur IKE, poursuivant la négociation en mode principal IKE.
7. Homologue 1 et Homologue 2 terminent la négociation IKE en mode principal et en mode rapide.
8. Les segments suivants envoyés sur la connexion TCP sont protégés avec IPSec.

Exemple 3 : Homologue IPsec basé sur Windows Vista en mode de requête et homologue IPSec basé sur Windows XP en mode d'exigence

Dans cet exemple, un homologue IPSec basé sur Windows Vista (Homologue 1) est l'initiateur et le répondeur exécute Windows XP (Homologue 2). L'homologue 1 est configuré avec le mode de requête pour les communications sortantes et l'homologue 2 est configuré avec le mode d'exigence pour les communications entrantes. En mode d'exigence, un homologue IPSec requiert la protection IPSec et rejette silencieusement les paquets non protégés. Les messages échangés sont les suivants :

1. Homologue 1 envoie un segment TCP SYN en texte clair établissant une connexion TCP, qu'Homologue 2 rejette silencieusement.
2. Homologue 1 envoie un message ISAKMP basé sur AuthIP, établissant le mode de négociation principal AuthIP, que Homologue 2 rejette silencieusement.
3. Homologue 1 envoie un message ISAKMP basé sur IKE, établissant une négociation en mode principal IKE.
4. Homologue 2 répond par un message ISAKMP basé sur IKE, poursuivant la négociation en mode principal IKE.
5. Homologue 1 et Homologue 2 terminent la négociation IKE en mode principal et en mode rapide.
6. Homologue 1 retransmet le segment TCP SYN (protégé avec IPsec).
7. Homologue 2 envoie le segment TCP SYN-ACK (protégé avec IPsec).
8. Homologue 1 envoie le segment TCP ACK (protégé avec IPsec).

IKE est une norme Internet, définie dans la RFC 2409 (ietf.org/rfc/rfc2409.txt), qui définit un mécanisme d'établissement des associations de sécurité IPSec (les SA). Une SA est une combinaison de clés et de stratégie fixée par accord mutuel qui définit les services et mécanismes de sécurité qui aident à protéger la communication entre les homologues IPSec. En particulier, IKE combine le protocole ISAKMP (Internet Security Association and Key Management Protocol) de la RFC 2408 et le protocole Oakley Key Determination (RFC 2412). IKE utilise le protocole Oakley Key Determination pour générer le matériel de clé secret pour les communications protégées.

IKE utilise ISAKMP pour négocier des SA. ISAKMP inclut des options pour l'identification et l'authentification des homologues, la gestion des SA et l'échange du matériel de clé. ISAKMP est une infrastructure pour la négociation de communications protégées indépendante des protocoles d'échange de clés, des algorithmes de chiffrement et d'intégrité et des méthodes d'authentification spécifiques.

Les homologues IPsec utilisent IKE pour la négociation en mode principal et mode rapide. La négociation en mode principal crée la SA ISAKMP, qui protège les négociations de sécurité. Durant la négociation en mode principal, l'initiateur et le répondeur échangent une série de messages ISAKMP afin de négocier les algorithmes de chiffrement et de hachage pour la SA ISAKMP, l'échange de matériel de détermination de clé, et s'identifient et s'authentifient mutuellement.

Dans la phase de négociation en mode rapide, les deux SA IPSec (une SA pour les données entrantes et une SA pour les données sortantes) sont créées, ce qui protège les données envoyées entre deux homologues IPSec. Durant la négociation en mode rapide, l'initiateur et le répondeur échangent une série de messages ISAKMP chiffrés afin de négocier les algorithmes de chiffrement et de hachage pour les SA IPsec entrantes comme sortantes.

Pour plus d'informations sur le mode principal et le mode rapide basés sur IKE, consultez l'article « Négociation IKE pour les associations de sécurité IPSec » à l'adresse microsoft.com/technet/community/columns/cableguy/cg0602.mspx.

Présentation d'AuthIP

AuthIP est une version améliorée de IKE offrant une souplesse accrue avec prise en charge de l'authentification basée sur l'utilisateur, de l'authentification avec informations d'identification multiples, de la négociation de méthode d'authentification améliorée et de l'authentification asymétrique. Comme IKE, AuthIP prend en charge la négociation en modes principal et rapide. AuthIP prend également en charge le mode étendu, une partie de la négociation d'homologue IPSec pendant laquelle une deuxième session d'authentification peut être exécutée. Le mode étendu, qui est facultatif, peut être utilisé pour les authentifications multiples. Par exemple, en mode étendu, vous pouvez effectuer des authentifications séparées basées sur l'ordinateur ou basées sur l'utilisateur.

La prise en charge de l'authentification multiple fait partie de la mise en œuvre d'IPSec pour la plate-forme de protection d'accès réseau (NAP), dans laquelle les homologues IPSec s'authentifient avec les informations d'identification de l'ordinateur et utilisent également un certificat d'état pour prouver qu'ils sont conformes aux exigences d'état système. Pour plus d'informations sur la protection d'accès réseau, consultez la page microsoft.com/nap. Pour de plus amples renseignements sur les fonctionnalités d'AuthIP, consultez l'article « AuthIP dans Windows Vista » à l'adresse microsoft.com/technet/community/columns/cableguy/cg0806.mspx.

Messages AuthIP

IKE et AuthIP utilisent tous deux ISAKMP comme protocole d'échange de clés et de négociation de SA. Les messages ISAKMP sont envoyés via le protocole UDP (User Datagram Protocol) et consistent en un en-tête ISAKMP et une ou plusieurs charges utiles ISAKMP. L'en-tête ISAKMP contient des informations sur le message, notamment le type de message. La figure 1 représente le format de l'en-tête ISAKMP.

Figure 1** Format de l'en-tête ISAKMP **

Dans l'en-tête ISAKMP, le cookie d'initiation et le cookie de réponse sont définis sur un nombre aléatoire différent de zéro choisi par les homologues IPSec. Le champ Charge utile suivante indique la première charge utile du message ISAKMP, juste après l'en-tête ISAKMP. La RFC 2408 répertorie les valeurs définies dans le champ Charge utile. Les types de charge utile 128 à 255 sont réservés pour l'utilisation privée. Les champs Version principale et Version secondaire indiquent les versions d'ISAKMP sur l'homologue IPSec envoyant le message ISAKMP. Pour IKE et AuthIP, la version principale est 1 et la version secondaire est 0.

Le champ Type d'échange indique le type d'échange ISAKMP effectué. Le type d'échange détermine la structure et l'ordre des charges utiles ISAKMP. La RFC 2408 répertorie les valeurs définies dans le champ Type d'échange. Les types d'échange 128 à 255 sont réservés pour l'utilisation privée.

Le champ Indicateurs contient trois indicateurs définis dans la RFC 2408. Le bit le moins significatif (le bit 0) est le bit de chiffrement, qui indique que les charges utiles ISAKMP sont chiffrées (lorsqu'il est défini sur 1) ou ne sont pas chiffrées (lorsqu'il est défini sur 0). Le chiffrement est effectué en utilisant l'algorithme négocié pour la SA ISAKMP, qui est identifié par la combinaison des champs Cookie d'initiation et Cookie de réponse. Le bit le moins significatif suivant (bit 1) est le bit Commit, qui indique que l'échange de clés est synchronisé (lorsqu'il est défini sur 1) ou n'est pas synchronisé (lorsqu'il est défini sur 0). Le bit Commit est utilisé pour s'assurer que la SA termine sa négociation avant que les données chiffrées soient envoyées. Le bit le moins significatif suivant (bit 2) est le bit Authentication Only, qui est utilisé pour indiquer que le message contient (lorsqu'il est défini sur 1) ou ne contient pas (lorsqu'il est défini sur 0) l'intégralité de la charge utile Notify du type d'échange informationnel et qu'il a été authentifié mais n'a pas été chiffré.

Le champ ID de message contient un identificateur unique au message. ID de message est utilisé pour empêcher les collisions lorsque les deux homologues IPSec tentent simultanément d'établir une SA IPSec. Le champ Longueur indique la longueur du message ISAKMP entier.

Pour IKE, le message ISAKMP contient une série de charges utiles ISAKMP. La première charge utile est indiquée par le champ Charge utile suivante de l'en-tête ISAKMP. Chaque charge utile ISAKMP possède son propre champ Charge utile suivante pour indiquer la charge utile suivante. Le champ Charge utile suivante de la dernière charge utile est défini sur 0. La figure 2 correspond au format des messages IKE.

Figure 2** Format des messages IKE **

AuthIP utilise les messages ISAKMP avec les types d'échange 243 (mode principal), 244 (mode rapide), 245 (mode prolongé) et 246 (Notification) dans le champ Type d'échange de l'en-tête ISAKMP. Une différence importante dans les messages ISAKMP basés sur AuthIP est qu'ils contiennent seulement une charge utile ISAKMP : la charge utile Crypto ou Notify. La charge utile Crypto contient les charges utiles intégrées utilisées pour la négociation en mode principal, mode rapide ou mode étendu. La charge utile Crypto peut contenir une série de charges utiles en texte clair ou chiffrées, en fonction du bit Encryption du champ Indicateurs de l'en-tête ISAKMP. La figure 3 correspond au format des messages AuthIP contenant la charge utile Crypto.

Figure 3** Format des messages AuthIP contenant la charge utile Crypto **

Coexistence d'AuthIP et IKE

Windows Vista® et Windows Server® 2008 prennent tous deux en charge IKE et AuthIP. Cependant, Windows® XP et Windows Server 2003 prennent uniquement en charge IKE. Un homologue IPSec initiateur qui prend en charge AuthIP comme IKE et possède une stratégie de sécurité de connexion utilisant AuthIP et IKE doit déterminer si l'homologue PSec répondant prend en charge AuthIP ou IKE. Il doit ensuite utiliser le protocole le plus approprié pour la négociation de la protection IPSec, en préférant l'utilisation d'AuthIP à celle d'IKE.

Pour déterminer le protocole de négociation de l'homologue IPSec répondant, un homologue IPSec initiateur qui utilise AuthIP et IKE envoie simultanément les messages suivants :

• Message 1 : message AuthIP établissant la négociation en mode principal
• Message 1 : message IKE établissant la négociation en mode principal

Si le nœud répondant prend en charge AuthIP, il doit répondre au Message 1 avec un message AuthIP poursuivant la négociation en mode principal et rejeter silencieusement Message 2. Un nœud répondant qui ne prend pas en charge AuthIP rejette silencieusement Message 1 car le champ Type d'échange qu'il contient possède une valeur qu'il ne prend pas en charge, et répond au Message 2.

Pour empêcher la négociation basée sur IKE entre deux homologues IPSec exécutant Windows Vista ou Windows Server 2008 lorsque Message 1 est abandonné par le réseau ou arrive après Message 2, les homologues IPsec exécutant Windows Vista ou Windows Server 2008 envoient Message 2 avec une charge utile Supported Vendor ID ISAKMP prise en charge par AuthIP. La charge utile Supported Vendor ID AuthIP indique que l'homologue IPsec prend en charge AuthIP.

Par conséquent, si un homologue IPSec exécutant Windows Vista ou Windows Server 2008 reçoit Message 2 avec la charge utile Supported Vendor ID AuthIP, il attend que l'homologue IPSec initiateur retransmette Message 1 et Message 2, et répond à Message 1.

L'homologue IPSec initiateur continue à retransmettre les messages 1 et 2 jusqu'à ce qu'il reçoive une réponse ou arrive à expiration. Lorsque l'initiateur reçoit une réponse, il détermine la capacité du répondeur d'après l'en-tête ISAKMP de la réponse. Si Type d'échange est défini sur 243 (type d'échange de la négociation en mode principal basée sur AuthIP), le répondeur prend en charge AuthIP. Si Type d'échange est défini sur 2 (type d'échange de la protection d'identité et de la négociation en mode principal basée sur IKE), le répondeur prend en charge IKE.

En fonction de la réponse, l'initiateur répond avec le message AuthIP suivant pour la négociation en mode principal AuthIP ou le message IKE suivant pour la négociation en mode principal IKE. Les homologues IPSec doivent utiliser le protocole qui a été utilisé pour négocier la SA ISAKMP pendant toute sa durée de vie.

Joseph Davy est rédacteur technique chez Microsoft et auteur de la rubrique en ligne mensuelle TechNet Le petit câbleur sur Microsoft.com/technet/community/columns/cableguy.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.