3.3. Charge utile SA

La charge utile Security Association (SA), désignée sous le nom de SA dans ce document, sert à négocier les attributs d'une association de sécurité. L'assemblage d'une charge utile SA exige une grande patience. Une charge utile SA peut contenir plusieurs propositions (Proposals). S'il y a plusieurs propositions, elles DOIVENT être ordonnées de la plus préférée à la moins préférée. Chaque proposition contient un seul protocole IPsec (le protocole peut être IKE, ESP ou AH), et chaque protocole peut contenir plusieurs transformations (Transforms), chacune pouvant contenir plusieurs attributs (Attributes). Lors de l'analyse d'une SA, l'implémentation DOIT vérifier que la Payload Length totale est cohérente avec les longueurs et compteurs internes de cette charge utile. Les propositions, transformations et attributs ont chacun un encodage de longueur variable. Ils sont imbriqués de sorte que la Payload Length de la SA englobe le contenu fusionné des informations SA, proposition, transformation et attribut. La longueur d'une proposition englobe toutes les transformations et attributs qu'elle contient. La longueur d'une transformation englobe tous les attributs qu'elle contient.

La syntaxe de l'association de sécurité, de la proposition, de la transformation et de l'attribut est basée sur ISAKMP ; leur sémantique diffère toutefois. La raison de cette complexité et de cette structure hiérarchique est de permettre l'encodage de plusieurs combinaisons possibles d'algorithmes au sein d'une seule SA. Parfois, il faut choisir entre plusieurs algorithmes, parfois il s'agit d'une combinaison d'algorithmes. Par exemple, l'initiateur peut vouloir proposer ESP associé à (3DES et HMAC_MD5) ou (AES et HMAC_SHA1).

L'une des raisons pour lesquelles la sémantique de la charge utile SA a changé par rapport à ISAKMP et IKEv1 est de rendre l'encodage plus compact dans les cas courants.

La structure de proposition contient un numéro de proposition et un identifiant de protocole IPsec. Chaque structure DOIT avoir un numéro supérieur de 1 à la structure précédente. La première proposition de la charge utile SA de l'initiateur DOIT avoir le numéro de proposition 1 (un). L'une des raisons d'utiliser plusieurs propositions est de proposer simultanément des algorithmes de chiffrement standard et des algorithmes en mode combiné (combined-mode). Un algorithme en mode combiné intègre l'intégrité et le chiffrement dans un seul algorithme de chiffrement, et DOIT soit ne fournir aucun algorithme d'intégrité, soit fournir un seul algorithme d'intégrité « none », la méthode RECOMMANDÉE étant de ne pas fournir d'algorithme d'intégrité. Si l'initiateur souhaite proposer simultanément des algorithmes en mode combiné et normaux, il DOIT inclure deux propositions : l'une contenant tous les algorithmes en mode combiné, l'autre contenant tous les algorithmes normaux avec algorithmes d'intégrité. Par exemple, une telle proposition aurait deux structures de proposition. La proposition 1 est ESP avec AES-128, AES-192 et AES-256 en mode CBC, l'algorithme d'intégrité étant HMAC-SHA1-96 ou XCBC-96 ; la proposition 2 est AES-128 ou AES-256 en mode GCM avec une valeur de contrôle d'intégrité (ICV) de 8 octets. Les deux propositions autorisent, sans l'exiger, l'utilisation de ESN (numéro de séquence étendu). Cela peut se représenter ainsi :

Chaque structure proposition/protocole est suivie d'une ou plusieurs structures de transformation. Le nombre de transformations distinctes est généralement déterminé par le protocole. AH en a généralement deux : le numéro de séquence étendu (ESN) et un algorithme de vérification d'intégrité. ESP en a généralement trois : ESN, un algorithme de chiffrement et un algorithme de vérification d'intégrité. IKE en a généralement quatre : un groupe Diffie-Hellman, un algorithme de vérification d'intégrité, un algorithme PRF et un algorithme de chiffrement. Pour chaque protocole, l'ensemble des transformations autorisées se voit attribuer des numéros de Transform ID, qui apparaissent dans l'en-tête de chaque transformation.

S'il y a plusieurs transformations d'un même type de transformation, la proposition est un « OU » (OR) entre ces transformations. S'il y a plusieurs transformations de types différents, la proposition est un « ET » (AND) entre les différents groupes. Par exemple, pour proposer ESP associé à (3DES ou AES-CBC) et (HMAC_MD5 ou HMAC_SHA), la proposition ESP inclura deux candidats de type de transformation 1 (un pour 3DES, un pour AEC-CBC) ainsi que deux candidats de type de transformation 3 (un pour HMAC_MD5, un pour HMAC_SHA). Cela propose en effet quatre combinaisons d'algorithmes. Si l'initiateur ne souhaite proposer qu'un sous-ensemble de ces combinaisons, par exemple (3DES et HMAC_MD5) ou (IDEA et HMAC_SHA), cela ne peut pas être encodé sous forme de plusieurs transformations au sein d'une seule proposition. À la place, l'initiateur DOIT construire deux propositions distinctes, chacune contenant deux transformations.

Une transformation donnée PEUT avoir un ou plusieurs attributs. Les attributs sont nécessaires lorsqu'une transformation peut être utilisée de plusieurs façons (par exemple un algorithme de chiffrement à longueur de clé variable). La transformation spécifie l'algorithme, l'attribut spécifie la longueur de clé. La plupart des transformations n'ont pas d'attributs. Une transformation NE DOIT PAS avoir plusieurs attributs du même type. Pour proposer des valeurs alternatives pour un attribut (par exemple plusieurs longueurs de clé pour l'algorithme de chiffrement AES), l'implémentation DOIT inclure plusieurs transformations du même type, chacune avec un attribut distinct.

Notez que la sémantique des transformations et des attributs diffère fortement de celle de IKEv1. Dans IKEv1, une seule transformation portait plusieurs algorithmes pour un protocole, l'un transporté dans la transformation et les autres dans les attributs.

                 1                   2                   3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 6 :  Format de la charge utile SA

o Proposals (longueur variable) – une ou plusieurs sous-structures de proposition.

Le type de charge utile de la charge utile SA est trente-trois (33).

3.3.1. Sous-structure de proposition

                 1                   2                   3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (last) or 2 | RESERVED | Proposal Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Proposal Num | Protocol ID | SPI Size |Num Transforms| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SPI (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 7 :  Sous-structure de proposition

o 0 (dernier) ou 2 (plus) (1 octet) – indique s'il s'agit de la dernière sous-structure de proposition dans la SA. Cette syntaxe est héritée de ISAKMP, mais n'est pas nécessaire car la dernière proposition est identifiable par la longueur de la SA. La valeur (2) correspond au type de charge utile de la proposition dans IKEv1, et les quatre premiers octets de la structure de proposition ont été conçus pour ressembler à l'en-tête d'une charge utile.

o RESERVED (1 octet) – DOIT être envoyé à 0 ; DOIT être ignoré à la réception.

o Proposal Length (2 octets, entier non signé) – la longueur de cette proposition, y compris toutes les transformations et attributs qui la suivent.

o Proposal Num (1 octet) – lors de l'émission d'une proposition, la première proposition de la charge utile SA DOIT être 1, et les propositions suivantes DOIVENT être supérieures de 1 à la proposition précédente (ce qui exprime une relation « OU » entre deux propositions). Lorsqu'une proposition est acceptée, le numéro de proposition dans la charge utile SA DOIT correspondre au numéro de la proposition acceptée telle qu'emise.

o Protocol ID (1 octet) – indique l'identifiant de protocole IPsec en cours de négociation. Les valeurs du tableau ci-dessous n'étaient valides qu'à la date de publication de RFC 4306. D'autres valeurs peuvent avoir été ajoutées ou le seront. Les lecteurs doivent consulter [IKEV2IANA] pour les valeurs les plus récentes.

Protocol Protocol ID

IKE 1 AH 2 ESP 3

o SPI Size (1 octet) – pour la négociation initiale de la SA IKE, ce champ DOIT être 0 ; la SPI est obtenue à partir de l'en-tête externe. Lors des négociations ultérieures, il est égal à la taille de la SPI (en octets) du protocole correspondant (IKE : 8, ESP et AH : 4).

o Num Transforms (1 octet) – indique le nombre de transformations dans cette proposition.

o SPI (longueur variable) – la SPI de l'entité émettrice. Même si le champ SPI Size n'est pas un multiple de 4 octets, aucun remplissage n'est appliqué à la charge utile. Lorsque le champ SPI Size est 0, ce champ n'apparaît pas dans la charge utile Security Association.

o Transforms (longueur variable) – une ou plusieurs sous-structures de transformation.

3.3.2. Sous-structure de transformation

                 1                   2                   3

     Figure 8 :  Sous-structure de transformation

o 0 (dernier) ou 3 (plus) (1 octet) – indique s'il s'agit de la dernière sous-structure de transformation dans la proposition. Cette syntaxe est héritée de ISAKMP, mais n'est pas nécessaire car la dernière transformation est identifiable par la longueur de la proposition. La valeur (3) correspond au type de charge utile de la transformation dans IKEv1, et les quatre premiers octets de la structure de transformation ont été conçus pour ressembler à l'en-tête d'une charge utile.

o RESERVED – DOIT être envoyé à 0 ; DOIT être ignoré à la réception.

o Transform Length – la longueur de la sous-structure de transformation (en octets), y compris l'en-tête et les attributs.

o Transform Type (1 octet) – le type de transformation spécifié dans la proposition. Les différents protocoles prennent en charge différents types de transformation. Pour certains protocoles, certaines transformations peuvent être facultatives. Si une transformation est facultative et que l'initiateur souhaite proposer d'omettre cette transformation, il n'inclut pas de transformation de ce type dans la proposition. Si l'initiateur souhaite que la transformation soit facultative pour le répondeur, il inclut une sous-structure de transformation dont l'un des choix est Transform ID = 0.

o Transform ID (2 octets) – l'instance spécifique du type de transformation proposé.

Les valeurs du type de transformation sont présentées dans le tableau ci-dessous. Les valeurs du tableau ci-dessous n'étaient valides qu'à la date de publication de RFC 4306. D'autres valeurs peuvent avoir été ajoutées ou le seront. Les lecteurs doivent consulter [IKEV2IANA] pour les valeurs les plus récentes.

Description Trans. Used In Type

Encryption Algorithm (ENCR) 1 IKE and ESP Pseudorandom Function (PRF) 2 IKE Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP Diffie-Hellman group (D-H) 4 IKE, optional in AH & ESP Extended Sequence Numbers (ESN) 5 AH and ESP

(*) En ce qui concerne le format de charge utile de chiffrement défini dans ce document, la négociation d'un algorithme d'intégrité est obligatoire. Par exemple, [AEAD] définit un format supplémentaire basé sur le chiffrement authentifié (authenticated encryption), dans lequel aucun algorithme d'intégrité séparé n'est négocié.

Pour le type de transformation 1 (algorithme de chiffrement), la Transform ID est présentée dans le tableau ci-dessous. Les valeurs du tableau ci-dessous n'étaient valides qu'à la date de publication de RFC 4306. D'autres valeurs peuvent avoir été ajoutées ou le seront. Les lecteurs doivent consulter [IKEV2IANA] pour les valeurs les plus récentes.

Name Number Defined In

ENCR_DES_IV64 1 (UNSPECIFIED) ENCR_DES 2 (RFC2405), [DES] ENCR_3DES 3 (RFC2451) ENCR_RC5 4 (RFC2451) ENCR_IDEA 5 (RFC2451), [IDEA] ENCR_CAST 6 (RFC2451) ENCR_BLOWFISH 7 (RFC2451) ENCR_3IDEA 8 (UNSPECIFIED) ENCR_DES_IV32 9 (UNSPECIFIED) ENCR_NULL 11 (RFC2410) ENCR_AES_CBC 12 (RFC3602) ENCR_AES_CTR 13 (RFC3686)

Pour le type de transformation 2 (fonction pseudo-aléatoire), la Transform ID est présentée dans le tableau ci-dessous. Les valeurs du tableau ci-dessous n'étaient valides qu'à la date de publication de RFC 4306. D'autres valeurs peuvent avoir été ajoutées ou le seront. Les lecteurs doivent consulter [IKEV2IANA] pour les valeurs les plus récentes.

Name Number Defined In

PRF_HMAC_MD5 1 (RFC2104), [MD5] PRF_HMAC_SHA1 2 (RFC2104), [SHA] PRF_HMAC_TIGER 3 (UNSPECIFIED)

Pour le type de transformation 3 (algorithme d'intégrité), les Transform ID définies sont présentées dans le tableau ci-dessous. Les valeurs du tableau ci-dessous n'étaient valides qu'à la date de publication de RFC 4306. D'autres valeurs peuvent avoir été ajoutées ou le seront. Les lecteurs doivent consulter [IKEV2IANA] pour les valeurs les plus récentes.

Name Number Defined In

NONE 0 AUTH_HMAC_MD5_96 1 (RFC2403) AUTH_HMAC_SHA1_96 2 (RFC2404) AUTH_DES_MAC 3 (UNSPECIFIED) AUTH_KPDK_MD5 4 (UNSPECIFIED) AUTH_AES_XCBC_96 5 (RFC3566)

Pour le type de transformation 4 (groupe Diffie-Hellman), les Transform ID définies sont présentées dans le tableau ci-dessous. Les valeurs du tableau ci-dessous n'étaient valides qu'à la date de publication de RFC 4306. D'autres valeurs peuvent avoir été ajoutées ou le seront. Les lecteurs doivent consulter [IKEV2IANA] pour les valeurs les plus récentes.

Name Number Defined In

NONE 0 768-bit MODP 1 Appendix B 1024-bit MODP 2 Appendix B 1536-bit MODP 5 [ADDGROUP] 2048-bit MODP 14 [ADDGROUP] 3072-bit MODP 15 [ADDGROUP] 4096-bit MODP 16 [ADDGROUP] 6144-bit MODP 17 [ADDGROUP] 8192-bit MODP 18 [ADDGROUP]

Bien qu'ESP et AH n'incluent pas directement un échange Diffie-Hellman, un groupe Diffie-Hellman PEUT être négocié pour une Child SA. Cela permet au pair d'utiliser Diffie-Hellman dans un échange CREATE_CHILD_SA afin de fournir un secret progressif parfait (perfect forward secrecy) pour les clés de la Child SA générée.

Pour le type de transformation 5 (numéros de séquence étendus), les Transform ID définies sont présentées dans le tableau ci-dessous. Les valeurs du tableau ci-dessous n'étaient valides qu'à la date de publication de RFC 4306. D'autres valeurs peuvent avoir été ajoutées ou le seront. Les lecteurs doivent consulter [IKEV2IANA] pour les valeurs les plus récentes.

Name Number

No Extended Sequence Numbers 0 Extended Sequence Numbers 1

Notez qu'un initiateur prenant en charge ESN inclut généralement deux transformations ESN dans sa proposition, avec les valeurs « 0 » et « 1 ». Une proposition contenant une seule transformation ESN de valeur « 1 » signifie que l'utilisation de numéros de séquence normaux (non étendus) n'est pas acceptable.

Depuis la publication de RFC 4306, de nombreux types de transformation supplémentaires ont été définis. Pour plus de détails, voir le registre IANA IKEv2.

3.3.3. Types de transformation valides par protocole

Le nombre et le type de transformations accompagnant une charge utile SA dépendent du protocole dans lequel la SA elle-même se trouve. Une proposition établissant une SA a les types de transformation obligatoires et facultatifs suivants. Une implémentation conforme DOIT comprendre tous les types obligatoires et facultatifs pour chaque protocole qu'elle prend en charge (bien qu'elle ne soit pas tenue d'accepter une proposition contenant un ensemble inacceptable). Si la seule valeur qu'elle accepterait pour un type facultatif est NONE, la proposition PEUT omettre ce type facultatif.

Protocol Mandatory Types Optional Types

IKE ENCR, PRF, INTEG*, D-H ESP ENCR, ESN INTEG, D-H AH INTEG, ESN D-H

(*) En ce qui concerne le format de charge utile de chiffrement défini dans ce document, la négociation d'un algorithme d'intégrité est obligatoire. Par exemple, [AEAD] définit un format supplémentaire basé sur le chiffrement authentifié, dans lequel aucun algorithme d'intégrité séparé n'est négocié.

3.3.4. Transform ID obligatoires

Les suites qui, dans ce document, DEVAIENT et DEVRAIENT être prises en charge pour l'interopérabilité ont été supprimées car elles risquent d'évoluer plus vite que ce document. Au moment de la publication du présent document, [RFC4307] définit ces suites ; notez toutefois qu'il pourra être mis à jour à l'avenir et que d'autres RFC pourraient définir des ensembles de suites différents.

Une leçon importante tirée de IKEv1 est la suivante : aucun système ne devrait implémenter uniquement les algorithmes obligatoires et s'attendre à ce qu'ils soient le meilleur choix pour tous les clients.

Il est très probable qu'IANA ajoute à l'avenir des transformations supplémentaires et que certains utilisateurs souhaitent utiliser des suites privées, notamment pour IKE ; les implémentations DEVRAIENT être capables de prendre en charge différents paramètres jusqu'à une limite de taille donnée. Pour soutenir cet objectif, toutes les implémentations IKEv2 DEVRAIENT inclure un outil d'administration permettant (à l'utilisateur ou à l'administrateur système) de spécifier les paramètres Diffie-Hellman (générateur, module ainsi que longueur et valeur de l'exposant) pour un nouveau groupe Diffie-Hellman. Les implémentations DEVRAIENT fournir une interface d'administration permettant de saisir ces paramètres ainsi que la Transform ID associée afin de permettre la négociation de tels groupes.

Toutes les implémentations IKEv2 DOIVENT inclure un outil d'administration permettant à l'utilisateur ou à l'administrateur système de spécifier les suites acceptables à utiliser avec IKE. Lors de la réception d'une charge utile contenant un ensemble de Transform ID, l'implémentation DOIT comparer les Transform ID transmises avec les Transform ID configurées localement via le contrôle d'administration afin de vérifier, conformément à la politique locale, que la suite proposée est acceptable. Les implémentations DOIVENT rejeter les propositions de SA non autorisées par ces contrôles de suites IKE. Notez que l'implémentation obligatoire des suites de chiffrement n'implique pas nécessairement qu'elles soient configurées comme acceptables pour la politique locale.

3.3.5. Attributs de transformation

Chaque transformation d'une charge utile Security Association PEUT contenir des attributs qui modifient ou précisent la spécification de la transformation. L'ensemble des attributs valides dépend de la transformation. À ce jour, un seul type d'attribut est défini : l'attribut Key Length (longueur de clé), utilisé par certaines transformations de chiffrement à clé de longueur variable (voir ci-dessous).

Les attributs sont des paires type/valeur, définies comme suit. Un attribut peut avoir une valeur fixe de deux octets ou une valeur de longueur variable. Dans ce dernier cas, l'attribut est encodé sous forme Type/Longueur/Valeur (TLV).

                 1                   2                   3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| Attribute Type | AF=0 Attribute Length | |F| | AF=1 Attribute Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AF=0 Attribute Value | | AF=1 Not Transmitted | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 9 :  Attribut de données

o Attribute Format (AF) (1 bit) – indique si l'attribut de données suit le format Type/Longueur/Valeur (TLV) ou le format abrégé Type/Valeur (TV). Si le bit AF est zéro (0), l'attribut utilise le format TLV ; si le bit AF est un (1), le format TV (avec une valeur de deux octets) est utilisé.

o Attribute Type (15 bits) – un identifiant unique pour chaque type d'attribut (voir ci-dessous).

o Attribute Value (longueur variable) – la valeur d'attribut associée au type d'attribut. Si le bit AF est zéro (0), ce champ a la longueur variable définie par le champ Attribute Length ; si le bit AF est un (1), la longueur de la valeur d'attribut est de 2 octets.

Le seul type d'attribut actuellement défini (Key Length) est de longueur fixe ; l'inclusion d'un encodage de longueur variable n'est prévue que pour de futures extensions. Les attributs décrits comme de longueur fixe NE DOIVENT PAS être encodés avec une longueur variable, sauf si leur longueur dépasse deux octets. Les attributs de longueur variable NE DOIVENT PAS être encodés en longueur fixe, même si leur valeur tient dans deux octets. Notez : cela diffère de IKEv1, où la flexibilité accrue pouvait simplifier l'écriture des messages, mais compliquait sans aucun doute les analyseurs.

Les valeurs du tableau ci-dessous n'étaient valides qu'à la date de publication de RFC 4306. D'autres valeurs peuvent avoir été ajoutées ou le seront. Les lecteurs doivent consulter [IKEV2IANA] pour les valeurs les plus récentes.

Attribute Type Value Attribute Format

Key Length (in bits) 14 TV

Les valeurs 0–13 ainsi que 15–17 ont été utilisées dans un contexte similaire dans IKEv1 et ne devraient pas être attribuées, sauf pour des valeurs correspondantes.

L'attribut Key Length spécifie la longueur de clé en bits (DOIT utiliser l'ordre des octets réseau) et s'applique à certaines transformations comme suit :

o L'attribut Key Length NE DOIT PAS être utilisé pour les transformations utilisant une clé de longueur fixe. Cela inclut ENCR_DES, ENCR_IDEA, ainsi que toutes les transformations de type 2 (fonction pseudo-aléatoire) et de type 3 (algorithme d'intégrité) définies dans ce document. Il est recommandé aux futures transformations de type 2 ou 3 de ne pas utiliser cet attribut.

o Certaines transformations exigent que l'attribut Key Length soit toujours inclus (l'omission de l'attribut n'est pas autorisée, et une proposition ne l'incluant pas DOIT être rejetée). Cela inclut par exemple ENCR_AES_CBC et ENCR_AES_CTR.

o Certaines transformations autorisent des clés de longueur variable tout en définissant une longueur de clé par défaut si l'attribut n'est pas inclus. Cela inclut par exemple ENCR_RC5 et ENCR_BLOWFISH.

Note d'implémentation : afin d'améliorer encore l'interopérabilité et de prendre en charge des points terminaux mis à niveau indépendamment, les implémentations de ce protocole DEVRAIENT accepter les valeurs qu'elles estiment offrir une sécurité supérieure. Par exemple, si le pair est configuré pour accepter une clé de longueur X bits pour un chiffrement donné, et qu'une clé plus longue pour le même chiffrement lui est proposée, l'implémentation DEVRAIT accepter la proposition si elle prend en charge l'utilisation d'une clé plus longue.

La prise en charge de cette capacité permet au répondeur d'exprimer le concept d'un niveau de sécurité « au moins » — « chiffre Y avec une clé d'au moins X bits ». Toutefois, comme l'attribut est toujours renvoyé tel quel (voir section suivante), un initiateur souhaitant accepter plusieurs longueurs de clé DOIT inclure plusieurs transformations du même type, chacune avec un attribut Key Length différent.

3.3.6. Négociation d'attributs

Lors de la négociation d'une association de sécurité, l'initiateur soumet des propositions au répondeur. Le répondeur DOIT sélectionner un seul ensemble complet de paramètres parmi les propositions (ou rejeter toutes les propositions s'il n'y en a aucune d'acceptable). S'il y a plusieurs propositions, le répondeur DOIT en sélectionner une seule. Si la proposition choisie comporte plusieurs transformations d'un même type, le répondeur DOIT en sélectionner une seule. Tous les attributs d'une transformation choisie DOIVENT être renvoyés tels quels. L'initiateur de l'échange DOIT vérifier que la proposition acceptée est cohérente avec l'une de ses propositions, et DOIT abandonner l'échange dans le cas contraire.

Si le répondeur reçoit une proposition contenant un type de transformation qu'il ne comprend pas, ou une proposition sans le type de transformation obligatoire, il DOIT considérer la proposition comme inacceptable ; toutefois, les autres propositions de la même charge utile SA sont traitées normalement. De même, si le répondeur reçoit une transformation qu'il ne comprend pas, ou une transformation contenant un attribut de transformation qu'il ne comprend pas, il DOIT considérer la transformation comme inacceptable ; les autres transformations du même type sont traitées normalement. Cela permet de définir à l'avenir de nouveaux types de transformation et attributs de transformation.

La négociation du groupe Diffie-Hellman présente quelques défis particuliers. La proposition SA contient dans le même message les attributs de la proposition et une valeur publique Diffie-Hellman (KE). Si, lors de l'échange initial, l'initiateur propose l'utilisation de l'un de plusieurs groupes Diffie-Hellman, il DEVRAIT choisir celui que le répondeur acceptera très probablement et inclure le KE correspondant. Si le répondeur sélectionne une proposition utilisant un groupe Diffie-Hellman différent (autre que NONE), il indique le groupe correct dans sa réponse, et l'initiateur DEVRAIT, lorsqu'il répète le premier message, choisir un élément de ce groupe comme valeur KE. Toutefois, il DEVRAIT continuer à proposer l'ensemble complet des groupes qu'il prend en charge, afin d'éviter une attaque de rétrogradation par un intermédiaire (man-in-the-middle). Si l'un des groupes proposés est le groupe Diffie-Hellman NONE et que le répondeur sélectionne ce groupe Diffie-Hellman, il DOIT ignorer la charge utile KE de l'initiateur et omettre la charge utile KE de sa réponse.