2.7. Négociation d'algorithmes

Chaque algorithme cryptographique pris en charge par une implémentation DOIT être spécifié avec un type d'attribut SA particulier, une valeur d'ID de transformation et tous les paramètres requis (tels que la longueur de clé). Ceux-ci sont listés dans [IKEV2IANA].

Dans une seule proposition SA, une implémentation peut lister plusieurs ensembles de transformations compatibles avec une proposition. Les membres de chaque ensemble DOIVENT tous être compatibles. Si l'ID de transformation "NONE" (valeur 0) est listé, cet ID de transformation DOIT être la seule transformation listée pour ce type. NONE n'est autorisé que pour les algorithmes d'intégrité. Un algorithme d'intégrité NONE signifie qu'aucune protection d'intégrité n'est fournie, à moins qu'un algorithme de chiffrement en mode combiné ne soit utilisé (voir section 3.3.2). Si un algorithme de chiffrement en mode combiné est sélectionné, aucun algorithme d'intégrité séparé ne devrait être spécifié pour l'algorithme de chiffrement, et MUST devrait être NONE (voir section 3.3.2). NONE DOIT être rejeté dans tous les autres cas.

L'initiateur DOIT proposer au moins une proposition prise en charge par son implémentation, et le répondeur DOIT accepter la première proposition prise en charge par son implémentation. En cas de multiples propositions compatibles, le comportement du répondeur est spécifique à l'implémentation. L'initiateur DOIT inclure uniquement des propositions prises en charge par son implémentation. Le répondeur PEUT rejeter une proposition valide s'il a déjà reçu du pair et proposé une proposition préférée dans un échange IKE précédent.

Pour négocier chaque protocole (IKE ou AH ou ESP), il DOIT y avoir au moins une proposition dans le payload SA, et chaque proposition DOIT contenir au moins une transformation de chaque type : au plus une transformation de chaque type (chiffrement, intégrité, PRF et DH), à moins que plusieurs transformations ne puissent pas être négociées séparément (par exemple un algorithme de chiffrement en mode combiné, qui inclut la protection d'intégrité mais pas en tant que transformation séparée). Le jeu de chiffrement lui-même peut être combiné, mais notez que les algorithmes combinés sont représentés comme une seule transformation dans le payload SA.

2.7.1. Sélection des jeux de chiffrement

Chaque implémentation DOIT implémenter les jeux de chiffrement suivants :

Chiffrement : ENCR_AES_CBC ainsi que l'algorithme de chiffrement AEAD ENCR_AES_GCM_16 (voir section 3.3.2). Les implémentations PEUVENT également implémenter ENCR_AES_CTR comme transformation AES alternative. Les implémentations PEUVENT implémenter ENCR_3DES, ENCR_DES, ENCR_CAST et ENCR_BLOWFISH, mais ils sont obsolètes et ne sont pas recommandés (SHOULD NOT) pour les nouvelles implémentations.
Fonction pseudo-aléatoire : PRF_HMAC_SHA1. Les implémentations DOIVENT implémenter PRF_HMAC_SHA1, et PEUVENT implémenter PRF_AES128_XCBC et PRF_HMAC_SHA2_256 ou PRF_HMAC_SHA2_384 ou PRF_HMAC_SHA2_512.
Intégrité : AUTH_HMAC_SHA1_96. Les implémentations DOIVENT implémenter AUTH_HMAC_SHA1_96, et PEUVENT implémenter AUTH_AES_XCBC_96, AUTH_HMAC_SHA2_256_128 ou AUTH_HMAC_SHA2_384_192 ou AUTH_HMAC_SHA2_512_256.
Groupes DH à domaine fini : les implémentations DOIVENT implémenter le groupe MODP 1024 bits 2 et le groupe EC 19. Les implémentations PEUVENT implémenter le groupe MODP 2048 bits 14 (ainsi que les groupes EC 20, 21, 23, 24 ou 25) comme alternative. L'interopérabilité entre les groupes EC et le groupe 2 n'est pas encore établie, mais l'avantage de la normalisation est de permettre aux déploiements de se normaliser sur un groupe donné, au cas où des implémentations plus récentes ne prendraient en charge que les groupes EC.
Les implémentations PEUVENT implémenter d'autres groupes Diffie-Hellman, mais ce n'est pas REQUIS.

Il semble que ce document ne devrait pas exiger l'implémentation d'algorithmes spécifiques, car les progrès de la cryptanalyse pourraient les rendre obsolètes ; cependant, si toutes les implémentations choisissaient différents ensembles d'algorithmes optionnels, l'interopérabilité serait impossible. Par conséquent, ce document définit un ensemble minimal d'algorithmes obligatoires et exige que de nouveaux algorithmes soient négociés avec ces algorithmes. Par conséquent, tous les algorithmes requis pour une implémentation devraient être obligatoires, normalisés (comme ci-dessus), ou devraient implémenter un des algorithmes obligatoires listés ci-dessus.

Les implémentations DEVRAIENT prendre en charge les certificats X.509 v3 pour l'identification ainsi que RSA et ECDSA irréversible (comme décrit dans [PKI] et [EAIKEv2]) pour la signature (dans le payload AUTH). Pour prendre en charge EAP, les implémentations DOIVENT prendre en charge l'authentification EAP. Les implémentations prenant en charge EAP DEVRAIENT prendre en charge la méthode EAP EAP-MSCHAPv2, et PEUVENT prendre en charge d'autres méthodes. La prise en charge de l'authentification par clé pré-partagée est fortement RECOMMANDÉE.

2.7.2. Renégociation

Dans une IKE SA, à moins que d'autres dispositions ne soient prises (par exemple, via un échange CREATE_CHILD_SA "volatil", voir section 2.18), l'ensemble de chiffrement des algorithmes de chiffrement négociés ne devrait pas (SHOULD NOT) changer pendant la durée de vie de la SA. Une renégociation PEUT être initiée pour remplacer une SA arrivant à expiration, ou pour négocier de nouvelles clés (basées sur certificat) ou une nouvelle identité pour une IKE SA existante, ou pour modifier les attributs de la IKE SA (par exemple, passer de l'authentification par clé pré-partagée à l'authentification par certificat). Pendant la renégociation, presque tout le flux de messages est répété, sauf qu'il est effectué à l'intérieur de la partie protégée de la IKE SA existante plutôt qu'en clair.

Puisque la renégociation utilise l'échange CREATE_CHILD_SA, elle a pour effet de créer une nouvelle child SA pour la IKE SA existante. L'initiateur PEUT ne spécifier aucun payload SA (y compris l'ID de protocole) dans l'échange CREATE_CHILD_SA, pour indiquer qu'il souhaite renégocier la IKE SA elle-même plutôt que créer une nouvelle child SA. Dans ce cas, lorsque l'échange CREATE_CHILD_SA est utilisé pour renégocier la IKE SA, il ne DOIT PAS être utilisé pour créer simultanément une child SA. Ce type d'échange est également appelé renégociation "de type 1".

Si l'initiateur inclut un payload SA dans l'échange CREATE_CHILD_SA, ce payload SA DOIT être utilisé pour créer une child SA (ou des child SA supplémentaires), tout en renégociant la IKE SA, et le répondeur DOIT l'accepter. Ce type d'échange est également appelé renégociation "de type 2". La prise en charge de la renégociation de type 2 n'est pas REQUIS.

2.7.3. Méthodes d'authentification prises en charge

Les implémentations DOIVENT prendre en charge les méthodes d'authentification suivantes :

Signature basée sur un chiffrement (voir section 3.8), utilisant les algorithmes RSA ou ECDSA irréversible, comme décrit dans [PKI] et [EAIKEv2].
Clé pré-partagée (voir sections 2.15 et 3.8).
Protocole d'authentification extensible (EAP), comme décrit dans [EAP].

Les implémentations PEUVENT prendre en charge d'autres méthodes d'authentification, mais ce n'est pas REQUIS.