2.15. Authentification de la IKE SA

Lorsque l'authentification extensible n'est pas utilisée (voir section 2.16), les pairs sont authentifiés en ayant chacun signé (ou calculé un MAC en utilisant un secret partagé rempli comme clé, comme décrit plus loin dans cette section) un bloc de données. Dans ces calculs, IDi' et IDr' sont les payloads ID entiers à l'exception de l'en-tête fixe. Pour le répondeur, les octets à signer commencent par le premier octet du premier SPI dans l'en-tête du second message (réponse IKE_SA_INIT) et se terminent par le dernier octet du dernier payload du second message. Y sont ajoutés (pour les besoins du calcul de la signature) le nonce Ni de l'initiateur (juste la valeur, pas le payload le contenant), et la valeur prf(SK_pr, IDr'). Notez que ni le nonce Ni ni la valeur prf(SK_pr, IDr') ne sont transmis. De même, l'initiateur signe le premier message (demande IKE_SA_INIT), en commençant par le premier octet du premier SPI dans l'en-tête et se terminant par le dernier octet du dernier payload. Y sont ajoutés (pour les besoins du calcul de la signature) le nonce Nr du répondeur, et la valeur prf(SK_pi, IDi'). Il est critique pour la sécurité de l'échange que chaque côté signe le nonce de l'autre côté.

Les octets signés par l'initiateur peuvent être décrits comme :

Les octets signés par le répondeur peuvent être décrits comme :

Notez que tous les payloads sont inclus sous la signature, y compris tout type de payload non défini dans ce document. Si le premier message de l'échange est envoyé plusieurs fois (tel qu'avec un cookie de répondeur et/ou un groupe Diffie-Hellman différent), c'est la dernière version du message qui est signée.

Optionnellement, les messages 3 et 4 PEUVENT inclure un certificat, ou une chaîne de certificats fournissant la preuve que la clé utilisée pour calculer une signature numérique appartient au nom dans le payload ID. La signature ou le MAC sera calculé en utilisant les algorithmes dictés par le type de clé utilisé par le signataire, et spécifiés par le champ Méthode d'authentification dans le payload Authentication. Il n'est pas requis (REQUIRED) que l'initiateur et le répondeur signent avec les mêmes algorithmes cryptographiques. Le choix des algorithmes cryptographiques dépend du type de clé que chacun possède. En particulier, l'initiateur peut utiliser une clé partagée alors que le répondeur peut avoir une clé de signature publique et un certificat. Il sera généralement le cas (mais ce n'est pas requis) que, si un secret partagé est utilisé pour l'authentification, la même clé est utilisée dans les deux directions.

Notez qu'il est une pratique courante mais typiquement peu sûre d'avoir une clé partagée dérivée uniquement d'un mot de passe choisi par l'utilisateur sans incorporer une autre source d'aléa. Cela est typiquement peu sûr parce que les mots de passe choisis par l'utilisateur ont peu de chances d'avoir une imprévisibilité suffisante pour résister aux attaques par dictionnaire, et ces attaques ne sont pas prévenues par cette méthode d'authentification. (Les applications utilisant l'authentification par mot de passe pour l'amorçage et la IKE SA devraient utiliser la méthode d'authentification de la section 2.16, qui est conçue pour prévenir les attaques par dictionnaire hors ligne.) La clé pré-partagée doit contenir autant d'imprévisibilité que la clé la plus forte négociée. Dans le cas d'une clé pré-partagée, la valeur AUTH est calculée comme suit :

Pour l'initiateur : AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), ) Pour le répondeur : AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), )

où la chaîne "Key Pad for IKEv2" est de 17 caractères ASCII sans termination nulle. La clé partagée peut être de longueur variable. La chaîne de remplissage est ajoutée afin que si la clé partagée est dérivée d'un mot de passe, l'implémentation IKE n'ait pas besoin de stocker le mot de passe en clair, mais puisse plutôt stocker la valeur prf(Shared Secret,"Key Pad for IKEv2"), qui ne pourrait pas être utilisée comme équivalent de mot de passe pour des protocoles autres que IKEv2. Comme noté ci-dessus, dériver la clé partagée d'un mot de passe n'est pas sûr. Cette construction est utilisée parce qu'il est anticipé que les gens le feront de toute façon. L'interface de gestion par laquelle la clé partagée est fournie DOIT accepter des chaînes ASCII d'au moins 64 octets et NE DOIT PAS ajouter de termination nulle avant de les utiliser comme clés partagées. Elle DOIT également accepter un encodage hexadécimal de la clé partagée. L'interface de gestion PEUT accepter d'autres encodages si l'algorithme pour traduire l'encodage en une chaîne binaire est spécifié.

Il y a deux types d'authentification EAP (décrits dans la section 2.16), et chaque type utilise des valeurs différentes dans les calculs AUTH montrés ci-dessus. Si la méthode EAP génère une clé, substituez la clé de session maître (MSK) à la clé partagée dans le calcul. Pour les méthodes ne générant pas de clé, substituez respectivement SK_pi et SK_pr à la clé partagée dans les deux calculs AUTH.

2.15. Authentification de la IKE SA​

2.15. Authentification de la IKE SA