Partie I Introduction à l'administration système : services IP
1. Suite de protocoles réseau TCP/IP Oracle Solaris (présentation)
Partie II Administration TCP/IP
2. Planification de votre réseau TCP/IP (tâches)
4. Planification d'un réseau IPv6 (tâches)
5. Configuration des services réseau TCP/IP et de l'adressage IPv4 (tâches)
6. Administration d'interfaces réseau (tâches)
7. Configuration d'un réseau IPv6 (tâches)
8. Gestion d'un réseau TCP/IP (tâches)
9. Dépannage des problèmes de réseau (tâches)
10. Présentation détaillée de TCP/IP et IPv4 (référence)
11. Présentation détaillée de IPv6 (référence)
12. À propos de DHCP (présentation)
13. Planification pour le service DHCP (liste des tâches)
14. Configuration du service DHCP (tâches)
15. Administration de DHCP (tâches)
16. Configuration et administration du client DHCP
17. Résolution des problèmes DHCP (référence)
18. Commandes et fichiers DHCP (référence)
19. Architecture IPsec (présentation)
20. Configuration d'IPsec (tâches)
21. Architecture IPsec (référence)
22. Protocole IKE (présentation)
Terminologie relative aux clés IKE
Protocole IKE et accélération matérielle
Protocole IKE et stockage matériel
Modifications apportées à IKE dans Solaris10
23. Configuration du protocole IKE (tâches)
25. IP Filter dans Oracle Solaris (présentation)
28. Administration de Mobile IP (tâches)
29. Fichiers et commandes de Mobile IP (références)
31. Administration d'IPMP (tâches)
Partie VII Qualité de service IP (IPQoS)
32. Présentation d'IPQoS (généralités)
33. Planification d'un réseau IPQoS (tâches)
34. Création du fichier de configuration IPQoS (tâches)
35. Démarrage et maintenance d'IPQoS (tâches)
36. Utilisation de la comptabilisation des flux et de la collecte statistique (tâches)
Le fichier de configuration /etc/inet/ike/config contient des entrées de stratégie IKE. Pour que deux démons IKE puissent s'authentifier mutuellement, les entrées doivent être valides et les numéros de clé doivent être disponibles. Les entrées des fichiers de configuration déterminent la façon dont les numéros de clé seront utilisés pour authentifier l'échange qui a lieu lors de la phase 1. Il y a deux possibilités : les clés prépartagées ou les certificats de clés publiques.
Si l'entrée est auth_method preshared, ce sont les clés prépartagées qui sont utilisées pour authentifier l'échange. Si auth_method possède une valeur autre que preshared, l'authentification s'effectue à l'aide de certificats de clés publiques. Ces certificats peuvent être autosignés ou installés par un fournisseur de PKI. Pour plus d'informations, reportez-vous à la page de manuel ike.config(4).
Les clés prépartagées sont créées par un administrateur sur un système. Elles sont ensuite partagées hors bande avec les administrateurs de systèmes distants. Prenez soin de créer de longues clés aléatoires et de protéger le fichier et la transmission hors bande. Les clés sont placées dans le fichier /etc/inet/secret/ike.preshared de chaque système. Le fichier ike.preshared est réservé à IKE et le fichier ipseckeys à IPsec. Toute compromission des clés du fichier ike.preshared compromet toutes les clés qui en sont dérivées.
Le système de clés prépartagées doit être identique au système distant de clés correspondant. Les clés sont liées à une adresse IP donnée. Elles sont plus sécurisées lorsqu'un administrateur contrôle les systèmes communicants. Pour plus d'informations, reportez-vous à la page de manuel ike.preshared(4).
Grâce aux certificats de clés publiques, les systèmes communicants n'ont plus besoin de partager de numéros de clé secrets hors bande. Les clés publiques utilisent le protocole Diffie-Hellman (DH) pour authentifier et négocier les clés. Les certificats de clés publiques peuvent être soit autosignés, soit certifiés par une autorité de certification (AC).
Les certificats de clés publiques autosignés sont créés par l'administrateur. La commande ikecert certlocal -ks permet de créer la partie privée des biclés du système. Le certificat autosigné est ensuite émis, au format X.509, par le système distant. Le certificat du système distant est entré à l'aide de la commande ikecert certdb pour la partie publique de la clé. Les certificats autosignés résident dans le répertoire /etc/inet/ike/publickeys des systèmes communicants. Lorsque vous utilisez l'option -T, les certificats résident sur le matériel connecté.
Les certificats autosignés sont à mi-chemin entre les clés prépartagées et les AC. Contrairement aux clés prépartagées, les certificats autosignés peuvent être utilisés sur une machine portable ou sur un système susceptible d'être renuméroté. Pour autosigner un certificat pour un système n'ayant pas de numéro fixe, utilisez un nom alternatif de DNS (www.example.org ) ou d'email (root@domain.org).
Les clés publiques peuvent être délivrées par un fournisseur de PKI ou une AC. Elles doivent être installées, avec les certificats AC qui les accompagnent, dans le répertoire /etc/inet/ike/publickeys. Lorsque vous utilisez l'option -T, les certificats résident sur le matériel connecté. Les fournisseurs émettent également des listes de révocation de certificats (LRC). Outre les clés et les certificats AC, vous devez également installer les LRC dans le répertoire /etc/inet/ike/crls.
Les certificats AC présentent l'avantage d'être certifiés par une organisation externe, et non par l'administrateur du site. Il s'agit en quelque sorte de certificats "certifiés". Comme les certificats autosignés, les certificats AC peuvent être utilisés sur une machine portable ou sur un système susceptible d'être renuméroté. Contrairement aux certificats autosignés, ils s'intègrent facilement aux environnement à grande échelle afin de protéger un grand nombre de systèmes communicants.