6.2. Méthodes d'authentification dans Libreswan
Libreswan prend en charge plusieurs méthodes d'authentification, chacune correspondant à un scénario différent.
Clé pré-partagée (PSK)
Pre-Shared Key (PSK) est la méthode d'authentification la plus simple. Pour des raisons de sécurité, n'utilisez pas de PSK plus courts que 64 caractères aléatoires. En mode FIPS, les PSK doivent respecter une exigence de force minimale en fonction de l'algorithme d'intégrité utilisé. Vous pouvez définir le PSK en utilisant la connexion authby=secret.
Clés RSA brutes
Raw RSA keys sont généralement utilisés pour les configurations IPsec statiques d'hôte à hôte ou de sous-réseau à sous-réseau. Chaque hôte est configuré manuellement avec les clés publiques RSA de tous les autres hôtes, et Libreswan met en place un tunnel IPsec entre chaque paire d'hôtes. Cette méthode n'est pas adaptée à un grand nombre d'hôtes.
Vous pouvez générer une clé RSA brute sur un hôte à l'aide de la commande ipsec newhostkey. Vous pouvez dresser la liste des clés générées à l'aide de la commande ipsec showhostkey. La ligne leftrsasigkey= est nécessaire pour les configurations de connexion qui utilisent des clés CKA ID. Utilisez l'option de connexion authby=rsasig pour les clés RSA brutes.
Certificats X.509
X.509 certificates sont couramment utilisés pour les déploiements à grande échelle avec des hôtes qui se connectent à une passerelle IPsec commune. Une autorité centrale certificate authority (CA) signe les certificats RSA pour les hôtes ou les utilisateurs. Cette autorité centrale est chargée de relayer la confiance, y compris les révocations d'hôtes ou d'utilisateurs individuels.
Par exemple, vous pouvez générer des certificats X.509 à l'aide de la commande openssl et de la commande NSS certutil. Libreswan lit les certificats d'utilisateur à partir de la base de données NSS en utilisant le pseudonyme des certificats dans l'option de configuration leftcert=. Vous devez donc fournir un pseudonyme lors de la création d'un certificat.
Si vous utilisez un certificat d'autorité de certification personnalisé, vous devez l'importer dans la base de données NSS (Network Security Services). Vous pouvez importer n'importe quel certificat au format PKCS #12 dans la base de données Libreswan NSS à l'aide de la commande ipsec import.
Libreswan requiert un identifiant de pair IKE (Internet Key Exchange) comme nom alternatif de sujet (SAN) pour chaque certificat de pair, comme décrit dans la section 3.1 de la RFC 4945. La désactivation de cette vérification en modifiant l'option require-id-on-certificated= peut rendre le système vulnérable aux attaques de type man-in-the-middle.
Utilisez l'option de connexion authby=rsasig pour l'authentification basée sur des certificats X.509 utilisant RSA avec SHA-2. Vous pouvez la limiter davantage pour les signatures numériques ECDSA utilisant SHA-2 en définissant authby= sur ecdsa et pour l'authentification basée sur les signatures numériques RSA Probabilistic Signature Scheme (RSASSA-PSS) avec SHA-2 via authby=rsa-sha2. La valeur par défaut est authby=rsasig,ecdsa.
Les certificats et les méthodes de signature authby= doivent correspondre. Cela permet d'améliorer l'interopérabilité et de préserver l'authentification dans un seul système de signature numérique.
Authentification NULL
NULL authentication est utilisé pour obtenir un chiffrement du maillage sans authentification. Elle protège contre les attaques passives mais pas contre les attaques actives. Toutefois, comme IKEv2 autorise les méthodes d'authentification asymétriques, l'authentification NULL peut également être utilisée pour l'IPsec opportuniste à l'échelle de l'internet. Dans ce modèle, les clients authentifient le serveur, mais les serveurs n'authentifient pas le client. Ce modèle est similaire à celui des sites web sécurisés utilisant TLS. Utilisez authby=null pour l'authentification NULL.
Protection contre les ordinateurs quantiques
Outre les méthodes d'authentification mentionnées précédemment, vous pouvez utiliser la méthode Post-quantum Pre-shared Key (PPK) pour vous protéger contre les attaques éventuelles d'ordinateurs quantiques. Les clients individuels ou les groupes de clients peuvent utiliser leur propre PPK en spécifiant un ID PPK qui correspond à une clé pré-partagée configurée hors bande.
L'utilisation d'IKEv1 avec des clés pré-partagées offre une protection contre les attaquants quantiques. La nouvelle conception d'IKEv2 n'offre pas cette protection de manière native. Libreswan propose l'utilisation de Post-quantum Pre-shared Key (PPK) pour protéger les connexions IKEv2 contre les attaques quantiques.
Pour activer la prise en charge optionnelle du PPK, ajoutez ppk=yes à la définition de la connexion. Pour exiger le PPK, ajoutez ppk=insist. Ensuite, chaque client peut recevoir un identifiant PPK avec une valeur secrète qui est communiquée hors bande (et de préférence sans risque quantique). Les PPK doivent être très aléatoires et ne pas être basés sur des mots du dictionnaire. L'ID PPK et les données PPK sont stockées sur ipsec.secrets, par exemple :
@west @east : PPKS "user1" "thestringismeanttobearandomstr"
L'option PPKS se réfère aux PPK statiques. Cette fonction expérimentale utilise des PPK dynamiques basés sur un pavé à usage unique. À chaque connexion, une nouvelle partie du tampon à usage unique est utilisée comme PPK. Lorsqu'elle est utilisée, la partie du PPK dynamique contenue dans le fichier est écrasée par des zéros afin d'empêcher sa réutilisation. S'il n'y a plus de matériel de tampon à usage unique, la connexion échoue. Voir la page de manuel ipsec.secrets(5) pour plus d'informations.
L'implémentation des PPK dynamiques est fournie en tant qu'aperçu technologique non pris en charge. À utiliser avec précaution.
