Protocole d échange de clés sur Internet (IKEv2)

Transcription

1 RFC 4306 page Kaufman & autres Grupe de travail Réseau C. Kaufman, éd., Micrsft Request fr Cmments : 4306 décembre 2005 RFC rendues bslètes : 2407, 2408, 2409 Rendue bslète par la RFC5996 Catégrie : En curs de nrmalisatin Traductin Claude Brière de L Isle Prtcle d échange de clés sur Internet (IKEv2) Statut de ce mémire Le présent dcument spécifie un prtcle de nrmalisatin Internet pur la cmmunauté de l'internet, qui appelle à la discussin et à des suggestins pur sn améliratin. Prière de se reprter à l'éditin en curs des "Nrmes de prtcle fficielles de l'internet" (STD 1) sur l'état de la nrmalisatin et le statut de ce prtcle. La distributin du présent mémire n'est sumise à aucune restrictin. Ntice de Cpyright Cpyright (C) The Internet Sciety (2005). Résumé Le présent dcument décrit la versin 2 du prtcle d échange de clés sur Internet (IKE, Internet Key Exchange). IKE est une cmpsante d IPsec utilisée pur effectuer l authentificatin mutuelle et établir et entretenir les assciatins de sécurité (SA). Cette versin de la spécificatin IKE cmbine les cntenus de dcuments précédemment distincts, incluant l assciatin de sécurité Internet et le prtcle de gestin de clés (ISAKMP, RFC 2408), IKE (RFC 2409), le dmaine Internet d interprétatin (DOI, RFC 2407), la traversée de traducteur d adresse réseau (NAT), l authentificatin traditinnelle, et l acquisitin d adresse distante. La versin 2 de IKE n interfnctinne pas avec la versin 1, mais le frmat d en-tête cmmun aux deux versins amène de façn nn ambiguë sur le même prt UDP. Table des matières 1 Intrductin Scénaris d utilisatin Les échanges initiaux L échange CREATE_CHILD_SA L échange INFORMATIONAL Messages d infrmatin en-dehrs d une IKE_SA Détails du prtcle IKE et variantes Utilisatins des temprisateurs de retransmissin Utilisatin des numérs de séquence pur l identifiant de message Taille de fenêtre pur les demandes en chevauchement Synchrnisatin d état et fin de temprisatin de cnnexin Numérs de versin et rétr cmpatibilité Témins Négciatin d algrithme cryptgraphique Renuvellement des clés Négciatin de sélecteur de trafic Nms ccasinnels Adresse et agilité d'accès Réutilisatin des expnentielles de Diffie-Hellman Génératin du matériel de clés Génératin du matériel de clés pur la IKE_SA Authentificatin de la IKE_SA Méthdes de prtcle d authentificatin extensible Génératin du matériel de clés pur les CHILD_SA Renuvellement des clés des IKE_SA en utilisant l échange CREATE_CHILD_SA...19

2 RFC 4306 page Kaufman & autres 2.19 Demande d une adresse interne sur un réseau distant Demande de la versin de l hmlgue Traitement des erreurs IPCmp Traversée de NAT Ntificatin explicite d encmbrement (ECN) Frmats d en-tête et de charge utile L en-tête IKE En-tête générique de charge utile Charge utile d assciatin de sécurité Charge utile d échange de clés Charges utiles d identificatin Charge utile de certificat Charge utile de demande de certificat Charge utile d authentificatin Charge utile de nm ccasinnel Charge utile de Ntificatin Charge utile de sélecteur de trafic Charge utile chiffrée Charge utile de cnfiguratin Charge utile de prtcle d authentificatin extensible (EAP) Exigences de cnfrmité Cnsidératins sur la sécurité Cnsidératins relatives à l IANA Remerciements Références Références nrmatives Références infrmatives...53 Appendice A : Résumé des changements depuis IKEv Appendice B : Grupes Diffie-Hellman...55 B.1 Grupe 1 MODP à 768 bits...55 B.2 Grupe 2 MODP à 1024 bits Intrductin La sécurité sur IP (IPsec) furnit la cnfidentialité, l intégrité des dnnées, le cntrôle d accès, et l authentificatin de la surce des dnnées aux datagrammes IP. Ces services snt furnis en maintenant un état partagé entre la surce et le cllecteur d un datagramme IP. Cet état définit, entre autres chses, les services spécifiques furnis au datagramme, quels algrithmes cryptgraphiques sernt utilisés pur furnir les services, et les clés utilisées cmme entrées des algrithmes cryptgraphiques. Établir cet état partagé de façn manuelle ne cnvient pas très bien. Il est dnc nécessaire d avir un prtcle pur établir cet état de façn dynamique. Le présent mémire décrit un tel prtcle l échange de clés sur Internet (IKE, Internet Key Exchange). Ceci est la versin 2 de IKE. La versin 1 de IKE était définie dans les RFC 2407, 2408, et 2409 [Pip98, MSST98, HC98]. Cet unique dcument est destiné à remplacer ces tris RFC. Les définitins des principaux termes de ce dcument (cmme Assciatin de sécurité u SA) se truvent dans la [RFC4301]. Les mts clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRAIT", "NE DEVRAIT PAS" et "PEUT" qui apparaissent dans le présent dcument snt à interpréter cmme décrit dans la [RFC2119]. Le terme"révisin d experts" est à interpréter cmme défini dans la [RFC2434]. IKE effectue l authentificatin mutuelle entre deux parties et établit une assciatin de sécurité (SA) IKE qui inclut les infrmatins de secret partagé qui peuvent être utilisées pur établir efficacement des SA pur l encapsulatin de charge utile de sécurité (ESP) [RFC4303] et/u l en-tête d authentificatin (AH) [RFC4302] et un ensemble d algrithmes cryptgraphiques utilisés par les SA pur prtéger le trafic qu elles prtent. Dans le présent dcument, le terme "suite" u "suite cryptgraphique" se réfère à un ensemble cmplet d algrithmes utilisés pur prtéger une SA. Un initiateur prpse une u plusieurs suites en faisant la liste des algrithmes pris en charge qui peuvent être cmbinés en suites seln un chix de cmbinaisns. IKE peut aussi négcier l utilisatin de la cmpressin IP (IPCmp, IP Cmpressin) [RFC3173] en cnnexin avec une SA ESP et/u AH. On appelle SA IKE une "IKE_SA". Les SA pur ESP et/u AH qui snt établies au myen de cette IKE_SA snt appelées "CHILD_SA" (SA filles). Tutes les cmmunicatins IKE cnsistent en paires de messages : une demande et une répnse. La paire est appelée un "échange". On appelle les premiers messages qui établissent une IKE_SA des échanges IKE_SA_INIT et IKE_AUTH et

3 RFC 4306 page Kaufman & autres les échanges IKE suivants les échanges CREATE_CHILD_SA u INFORMATIONAL. Dans le cas le plus curant, il y a un seul échange IKE_SA_INIT et un seul échange IKE_AUTH (un ttal de quatre messages) pur établir la IKE_SA et la première CHILD_SA. Dans des cas exceptinnels, il peut y avir plus qu un de chacun de ces échanges. Dans tus les cas, tus les échanges IKE_SA_INIT DOIVENT s achever avant tut autre type d échange, puis tus les échanges IKE_AUTH DOIVENT s achever, et ensuite un nmbre quelcnque d échanges CREATE_CHILD_SA et INFORMATIONAL peut survenir dans n imprte quel rdre. Dans certains scénaris, une seule CHILD_SA est nécessaire entre les pints d extrémité IPsec, et dnc, il n y aura pas d échanges supplémentaires. Des échanges ultérieurs PEUVENT être utilisés pur établir des CHILD_SA supplémentaires entre la même paire de pints d extrémité authentifiés et pur effectuer d entretien. Le flux de messages IKE cnsiste tujurs en une demande suivie par une répnse. Il est de la respnsabilité du demandeur de s assurer de leur fiabilité. Si la répnse n est pas reçue dans un certain intervalle de temprisatin, le demandeur dit réémettre la demande (u abandnner la cnnexin). La première demande/répnse d une sessin IKE (IKE_SA_INIT) négcie les paramètres de sécurité pur la IKE_SA, envie les nms ccasinnels (nnce), et envie les valeurs Diffie-Hellman. La secnde demande/répnse (IKE_AUTH) transmet les identités, pruve sa cnnaissance des secrets crrespndants aux deux identités, et établit une SA pur la première (et suvent seule) CHILD_SA AH et/u ESP. Les types d échanges ultérieurs snt CREATE_CHILD_SA (qui crée une CHILD_SA) et INFORMATIONAL (qui supprime une SA, rapprte des cnditins d erreur, u effectue d autres tâches d entretien). Chaque demande exige une répnse. Une demande INFORMATIONAL sans charge utile (autre que la charge utile vide Encrypted (chiffrée) exigée par la syntaxe) est cmmunément utilisée cmme un cntrôle d existence. Ces échanges ultérieurs ne peuvent pas être utilisés avant l achèvement des échanges initiaux. Dans la descriptin qui suit, n suppse qu aucune erreur ne survient. Les mdificatins au flux qui surviennent en cas d erreurs snt décrites au paragraphe Scénaris d utilisatin IKE est prévu pur la négciatin des SA ESP et/u AH dans un certain nmbre de scénaris différents, dnt chacun a ses prpres exigences particulières Tunnel de passerelle de sécurité à passerelle de sécurité ! Pint d'! Tunnel! Pint d'! sus-réseau!extrémité! IPsecl!extrémité! sus-réseau prtégé <-->!de tunnel!< >!de tunnel!<--> prtégét Figure 1 : Tunnel de passerelle de sécurité à passerelle de sécurité Dans ce scénari, aucun pint d extrémité de la cnnexin IP ne met en œuvre IPsec, mais les nœuds de réseau entre eux prtègent le trafic sur une partie du chemin. La prtectin est transparente pur les pints d extrémité, et dépend de l acheminement rdinaire pur envyer les paquets à travers les pints d extrémité du tunnel pur le traitement. Chaque pint d extrémité annncera l ensemble des adresses "derrière" lui, et les paquets sernt envyés en mde tunnel là ù l en-tête IP interne cntient les adresses IP des pints d extrémité réels Transprt de pint d extrémité à pint d extrémité ! Pint d'! Transprt IPsec! Pint d'!!extrémité! u SA mde tunnel!extrémité!!prtégé!< >!prtégé! Figure 2 : Pint d extrémité à pint d extrémité Dans ce scénari, les deux pints d extrémité de la cnnexin IP mettent en œuvre IPsec, cmme il est exigé des hôtes dans la [RFC4301]. Le mde transprt sera habituellement utilisé sans en-tête IP interne. Si il y a un en-tête IP interne, les adresses internes sernt les mêmes que les adresses externes. Une seule paire d adresses sera négciée pur les paquets à

4 RFC 4306 page Kaufman & autres prtéger par cette SA. Ces pints d extrémité PEUVENT mettent en œuvre des cntrôles d accès de cuche applicatin sur la base des identités authentifiées IPsec des participants. Ce scénari permet la sécurité de but en but qui a été un principe de base de l Internet depuis les [RFC1958] [RFC2775], et une méthde pur limiter les prblèmes inhérents à la cmplexité dans les réseaux ntés par la [RFC3439]. Bien que ce scénari puisse n être pas entièrement applicable à l IPv4 Internet, il a été dévelppé avec succès dans des scénaris spécifiques au sein d intranets utilisant IKEv1. Il devrait être plus largement activé durant la transitin vers IPv6 et avec l adptin de IKEv2. Il est pssible dans ce scénari qu un des pints d extrémité prtégés u les deux se truve derrière un nœud de traductin d adresse réseau (NAT, netwrk address translatin), auquel cas les paquets tunnelés devrnt être encapsulés en UDP de srte que les numérs d'accès dans les en-têtes UDP puissent être utilisés pur identifier les pints d extrémité individuels "derrière" le NAT (vir au paragraphe 2.23) Tunnel de pint d extrémité à passerelle de sécurité ! Pint d'! Tunnel! Pint d'! Sus-réseau!extrémité! IPsec!extrémité! prtégé!prtégé!< >!prtégé!<--- et/u Internet Figure 3 : Tunnel de pint d extrémité à passerelle de sécurité Dans ce scénari, un pint d extrémité prtégé (nrmalement un rdinateur prtable en déplacement) se cnnecte à sn réseau d entreprise au myen d un tunnel prtégé par IPsec. Il ne peut utiliser ce tunnel que pur accéder à des infrmatins sur le réseau d entreprise, u il peut tunneler tut sn trafic sur le réseau d entreprise afin de tirer parti de la prtectin furnie par un pare-feu d entreprise cntre les attaques fndées sur l Internet. Dans tus les cas, le pint d extrémité prtégé vudra une adresse IP assciée à la passerelle de sécurité de srte que les paquets qui lui snt returnés aillent à la passerelle de sécurité et lui sient tunnelés en retur. Cette adresse IP peut être statique u peut être alluée de façn dynamique par la passerelle de sécurité. À l appui de ce dernier cas, IKEv2 inclut un mécanisme pur que l initiateur demande une adresse IP pssédée par la passerelle de sécurité à utiliser pur la durée de sa SA. Dans ce scénari, les paquets vnt utiliser le mde tunnel. Sur chaque paquet prvenant du pint d extrémité prtégé, l entête IP externe cntiendra l adresse IP de surce assciée à sa lcalisatin actuelle (c est-à-dire, l adresse qui btiendra que le trafic sit acheminé directement au pint d extrémité) alrs que l en-tête IP interne cntiendra l adresse IP de surce alluée par la passerelle de sécurité (c est-à-dire, l adresse qui btiendra le trafic acheminé à la passerelle de sécurité pur transmissin au pint d extrémité). L adresse de destinatin externe sera tujurs celle de la passerelle de sécurité, alrs que l adresse de destinatin interne sera celle de la destinatin ultime du paquet. Dans ce scénari, il est pssible que le pint d extrémité prtégé sit derrière un NAT. Dans ce cas, l adresse IP telle que vue par la passerelle de sécurité ne sera pas la même que l adresse IP envyée par le pint d extrémité prtégé, et les paquets devrnt être encapsulés dans UDP afin d être acheminés crrectement Autres scénaris D autres scénaris snt pssibles, cmme le snt des cmbinaisns incrprées de ceux ci-dessus. Un exemple ntable cmbine les aspects des paragraphes et Un sus-réseau peut faire tus les accès externes à travers une passerelle de sécurité distante en utilisant un tunnel IPsec, avec les adresses sur le sus-réseau acheminées à la passerelle de sécurité par le reste de l Internet. Un exemple purrait être celui du réseau de rattachement de quelqu un qui serait virtuellement sur l Internet avec des adresses IP statiques bien que la cnnectivité sit furnie par un ISP qui allue une seule adresse IP de façn dynamique à la passerelle de sécurité de l utilisateur (les adresses IP statiques et un relais IPsec snt furnis par un tiers lcalisé ailleurs). 1.2 Les échanges initiaux Les cmmunicatins utilisant IKE cmmencent tujurs par les échanges IKE_SA_INIT et IKE_AUTH (appelés Phase 1 dans IKEv1). Ces échanges initiaux cnsistent nrmalement en quatre messages, bien que dans certains scénaris ce nmbre puisse être supérieur. Tutes les cmmunicatins utilisant IKE cnsistent en paires de demande/répnse. Nus décrirns d abrd l échange de base, puis les variantes. La première paire de messages (IKE_SA_INIT) négcie les algrithmes cryptgraphiques, les échanges de nms ccasinnels (nnce), et fait un échange Diffie-Hellman [DH].

5 RFC 4306 page Kaufman & autres La secnde paire de messages (IKE_AUTH) authentifie les messages précédents, échange les identités et certificats, et établit la première CHILD_SA. Des parties de ces messages snt chiffrées et prtégées en intégrité avec des clés établies à travers l échange IKE_SA_INIT, de srte que les identités snt cachées aux espins et tus les champs dans tus les messages snt authentifiés. Dans les descriptins suivantes, les charges utiles cntenues dans le message snt indiquées par les nms dnt la liste figure ci-dessus. Ntatin AUTH CERT CERTREQ CP D E EAP HDR IDi IDr KE Ni, Nr N SA TSi TSr V Charge utile (Authenticatin) authentificatin (Certificate) certificat (Certificate Request) demande de certificat Cnfiguratin (Delete) supprime (Encrypted) chiffré (Extensible Authenticatin) authentificatin extensible (IKE Header) en-tête IKE (Identificatin Initiateur) identificatin de l initiateur (Identificatin Répndant) identificatin du répndant (Key Exchange) échange de clés (Nnce) nm ccasinnel (Ntify) ntifie (Security Assciatin) assciatin de sécurité (Traffic Selectr Initiateur) sélecteur de trafic de l initiateur (Traffic Selectr Répndant) sélecteur de trafic du répndant (Vendr ID) identifiant de fabricant Les détails des cntenus de chaque charge utile snt décrits à la sectin 3. Les charges utiles qui peuvent apparaître facultativement sernt indiquées entre crchets, telles que [CERTREQ], qui indique qu une charge utile de demande de certificat peut facultativement être incluse. Les échanges initiaux snt cmme suit : Initiateur HDR, SAi1, KEi, Ni Répndant HDR cntient les indices des paramètres de sécurité (SPI, Security Parameter Indexes), les numérs de versin, et les fanins de diverses srtes. La charge utile SAi1 établit les algrithmes cryptgraphiques que l initiateur prend en charge pur la IKE_SA. La charge utile KE envie la valeur Diffie-Hellman de l initiateur. Ni est le nm ccasinnel de l initiateur. HDR, SAr1, KEr, Nr, [CERTREQ] Le répndant chisit une suite cryptgraphique d après les chix fferts par l initiateur et exprime ce chix dans la charge utile SAr1, cmplète l échange Diffie-Hellman avec la charge utile KEr, et envie sn nm ccasinnel dans la charge utile Nr. À ce pint de la négciatin, chaque partie peut générer un SKEYSEED, à partir duquel tutes les clés snt déduites pur cette IKE_SA. Tus les messages qui suivent snt chiffrés et prtégés en intégrité sauf les en-têtes. Les clés utilisées pur le chiffrement et la prtectin d intégrité snt déduites du SKEYSEED et snt appelées SK_e (chiffrement) et SK_a (authentificatin u prtectin d intégrité seln le cas). Une SK_e et SK_a séparée est calculée pur chaque directin. En plus des clés SK_e et SK_a déduites de la valeur DH pur la prtectin de la IKE_SA, une autre quantité SK_d est déduite et utilisée pur la dérivatin des matériaux de clés ultérieurs pur les CHILD_SA. La ntatin SK {... } indique que ces charges utiles snt chiffrées et prtégées en intégrité en utilisant les SK_e et SK_a de cette directin. HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} L initiateur affirme sn identité avec la charge utile IDi, pruve sa cnnaissance du secret crrespndant à IDi et prtège en intégrité le cntenu du premier message en utilisant la charge utile AUTH (vir au paragraphe 2.15). Il peut aussi envyer sn u ses certificats dans la u les charges utiles CERT et une liste de ses ancres de cnfiance dans la u les charges utiles CERTREQ. Si une charge utile CERT est incluse, le premier certificat furni DOIT cntenir la clé publique utilisée pur vérifier le champ AUTH. La charge utile facultative IDr permet à l initiateur de spécifier à laquelle des identités du répndant il veut parler. Ceci est utile lrsque la machine sur laquelle fnctinne le répndant héberge

6 RFC 4306 page Kaufman & autres plusieurs identités à la même adresse IP. L initiateur cmmence la négciatin d une CHILD_SA en utilisant la charge utile SAi2. Les champs finaux (cmmençant par SAi2) snt décrits avec l échange CREATE_CHILD_SA. HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr} Le répndant affirme sn identité avec la charge utile IDr, envie facultativement un u plusieurs certificats (à nuveau avec le certificat qui cntient la clé publique utilisée pur vérifier la AUTH qui figure en début sur la liste) authentifie sn identité et prtège l intégrité du secnd message avec la charge utile AUTH, et achève la négciatin d une CHILD_SA avec les champs supplémentaires décrits ci-dessus dans l échange CREATE_CHILD_SA. Les receveurs des messages 3 et 4 DOIVENT vérifier que tutes les signatures et MAC snt calculés crrectement et que les nms dans les charges utiles ID crrespndent aux clés utilisées pur générer la charge utile AUTH. 1.3 L échange CREATE_CHILD_SA Cet échange cnsiste en une seule paire demande/répnse, et était appelé échange de phase 2 dans IKEv1. Il PEUT être initié par l une u l autre extrémité de la IKE_SA après l achèvement des échanges initiaux. Tus les messages qui suivent l échange initial snt prtégés cryptgraphiquement en utilisant les algrithmes cryptgraphiques et les clés négciées dans les deux premiers messages de l échange IKE. Ces messages suivants utilisent la syntaxe de la charge utile chiffrée décrite au paragraphe Tus les messages ultérieurs incluent une charge utile chiffrée, même si dans le texte ils snt mentinnés cmme "vides". L un u l autre pint d extrémité peut initier un échange CREATE_CHILD_SA, aussi dans ce paragraphe, le terme "initiateur" se réfère au pint d extrémité qui prend l initiative de cet échange. Une CHILD_SA est créée par l envi d une demande CREATE_CHILD_SA. La demande CREATE_CHILD_SA PEUT facultativement cntenir une charge utile KE pur un échange Diffie-Hellman supplémentaire afin de permettre des garanties plus frtes de secret de transmissin pur la CHILD_SA. Le matériel de clés pur la CHILD_SA est une fnctin de SK_d cnstituée durant l établissement de la IKE_SA, des nms ccasinnels échangés durant l échange CREATE_CHILD_SA, et de la valeur Diffie-Hellman (si les charges utiles KE snt incluses dans l échange CREATE_CHILD_SA). Dans la CHILD_SA créée au titre de l échange initial, n NE DOIT PAS envyer de secnde charge utile KE ni de secnd nm ccasinnel. Les nms ccasinnels de l échange initial snt utilisés dans le calcul des clés pur la CHILD_SA. La demande CREATE_CHILD_SA cntient : Initiateur HDR, SK {[N], SA, Ni, [KEi], [TSi, TSr]} Répndant L initiateur envie une u des ffres de SA dans la charge utile SA, un nm ccasinnel dans la charge utile Ni, facultativement une valeur Diffie-Hellman dans la charge utile KEi, et les sélecteurs de trafic prpsés dans les charges utiles TSi et TSr. Si cet échange CREATE_CHILD_SA renuvelle les clés d une SA existante autre que la IKE_SA, la charge utile N de tête de type REKEY_SA DOIT identifier la SA dnt les clés snt renuvelées. Si cet échange CREATE_CHILD_SA n est pas de renuvellement de clés d une SA existante, la charge utile N DOIT être mise. Si l ffre de la SA inclut des grupes Diffie-Hellman différents, KEi DOIT être un élément du grupe que l initiateur s attend qu accepte le répndant. Si il se trmpe, l échange CREATE_CHILD_SA va échuer, et il devra faire un nuvel essai avec une KEi différente. Le message qui suit l en-tête est chiffré et le message incluant l en-tête est prtégé en intégrité en utilisant les algrithmes cryptgraphiques négciés pur la IKE_SA. La répnse CREATE_CHILD_SA cntient : HDR, SK {SA, Nr, [KEr], [TSi, TSr]} Le répndant réplique (en utilisant le même identifiant de message pur répndre) avec l ffre acceptée dans une charge utile SA, et une valeur Diffie-Hellman dans la charge utile KEr si KEi était inclus dans la demande et si la suite cryptgraphique chisie inclut ce grupe. Si le répndant chisit une suite cryptgraphique avec un grupe différent, il DOIT rejeter la demande. L initiateur DEVRAIT répéter la demande, mais cette fis avec une charge utile KEi prvenant

7 RFC 4306 page Kaufman & autres du grupe chisi par le répndant. Les sélecteurs de trafic pur le trafic à envyer sur cette SA snt spécifiés dans la charge utile TS, qui peut être un susensemble de ce que prpsait l initiateur de la CHILD_SA. Les sélecteurs de trafic snt mis si cette demande CREATE_CHILD_SA est utilisée pur changer la clé de la IKE_SA. 1.4 L échange INFORMATIONAL À divers mments du fnctinnement d une IKE_SA, les hmlgues peuvent désirer s envyer l un l autre des messages de cmmande cncernant des erreurs u des ntificatins de certains événements. Pur ce faire, IKE définit un échange INFORMATIONAL. Les échanges INFORMATIONAL ne DOIVENT survenir qu après les échanges initiaux et snt prtégés cryptgraphiquement avec les clés négciées. Les messages de cmmande qui appartiennent à une IKE_SA DOIVENT être envyés sus cette IKE_SA. Les messages de cmmande qui appartiennent aux CHILD_SA DOIVENT être envyés sus la prtectin de la IKE_SA qui les a générés (u sn successeur si la IKE_SA a été remplacée pur les besins d un renuvellement de clés). Les messages d un échange INFORMATIONAL cntiennent zér, une u plusieurs charges utiles Ntificatin, Delete, et Cnfiguratin. Le receveur d une demande d échange INFORMATIONAL DOIT envyer une répnse (autrement l envyeur va suppser que le message a été perdu dans le réseau et va le retransmettre). Cette répnse PEUT être un message sans charge utile. Le message de demande dans un échange INFORMATIONAL PEUT aussi ne pas cntenir de charge utile. C est la façn prévue par laquelle un pint d extrémité peut demander à un autre pint d extrémité de vérifier qu il est en vie. Les SA ESP et AH existent tujurs par paire, avec une SA dans chaque directin. Lrsque une SA est fermée, les deux membres de la paire DOIVENT être fermés. Lrsque les SA snt incrprées, cmme lrsque des dnnées (et les en-têtes IP si n est en mde tunnel) snt encapsulées d abrd avec IPCmp, puis avec ESP, et finalement avec AH entre la même paire de pints d extrémité, tutes les SA DOIVENT être supprimées ensemble. Chaque pint d extrémité DOIT clre ses SA entrantes et permettre à l autre pint d extrémité de clre l autre SA dans chaque paire. Pur supprimer une SA, un échange INFORMATIONAL avec une u plusieurs charges utiles Delete est envyé avec la liste des SPI (cmme elles devraient se truver dans les en-têtes des paquets entrants) des SA à supprimer. Le receveur DOIT clre les SA désignées. Nrmalement, la répnse de l échange INFORMATIONAL va cntenir les charges utiles Delete pur les SA appariées allant dans l autre directin. Il y a une exceptin. Si par hasard les deux extrémités d un ensemble de SA décident indépendamment de les clre, chacun peut envyer une charge utile Delete et les deux demandes peuvent se criser dans le réseau. Si un nœud reçit une demande de suppressin pur des SA pur lesquelles il a déjà prduit une demande Delete, il DOIT supprimer les SA srtantes tut en traitant la demande et les SA entrantes tut en traitant la répnse. Dans ce cas, les répnses NE DOIVENT PAS inclure les charges utiles Delete pur les SA supprimées, car il en résulterait une duplicatin de la suppressin et purrait en thérie supprimer la mauvaise SA. Un nœud DEVRAIT regarder les cnnexins à mitié clses cmme des anmalies et faire un audit de leur existence si elles devaient persister. Nter que la présente spécificatin ne spécifie nulle part de temprisatins, aussi il appartient aux pints d extrémité individuels de décider du temps d attente. Un nœud PEUT refuser d accepter des dnnées entrantes sur des cnnexins demi clses mais NE DOIT PAS les clre unilatéralement et réutiliser les SPI. Si l état de cnnexin devient suffisamment embruillé, un nœud PEUT clre la IKE_SA ; le faire clôt implicitement tutes les SA négciées sus elle. Il peut alrs recnstruire les SA dnt il a besin sur une base saine sus une nuvelle IKE_SA. L échange INFORMATIONAL se définit cmme : Initiateur HDR, SK {[N,] [D,] [CP,]...} Répndant HDR, SK {[N,] [D,] [CP],...} Le traitement d un échange INFORMATIONAL est déterminé par ses cmpsants de charge utile. 1.5 Messages d infrmatin en-dehrs d une IKE_SA Si un paquet IKE chiffré arrive sur l'accès 500 u 4500 avec un indice SPI nn recnnu, cela purrait être parce que le nœud de réceptin a eu une panne récente et perdu l état u à cause d un dysfnctinnement u d une attaque d un autre système. Si le nœud de réceptin a une IKE_SA active à l adresse IP d ù est venu le paquet, il PEUT envyer une ntificatin du paquet capricieux sur cette IKE_SA dans un échange INFORMATIONAL. S il n a pas une telle IKE_SA, il

8 RFC 4306 page Kaufman & autres PEUT envyer un message d infrmatin sans prtectin cryptgraphique à l adresse IP de surce. Un tel message ne fait pas partie d un échange infrmatinnel, et le nœud de réceptin NE DOIT PAS y répndre. Le faire purrait causer un message en bucle. 2 Détails du prtcle IKE et variantes Nrmalement, IKE écute et envie sur l'accès UDP 500, bien que les messages IKE puissent aussi être reçus sur l'accès UDP 4500 avec un frmat légèrement différent (vir au paragraphe 2.23). Cmme UDP est un prtcle de datagrammes (nn fiable) IKE inclut dans sa définitin la récupératin des erreurs de transmissin, y cmpris la perte de paquet, la répétitin de paquet, et le faux paquet. IKE est cnçu pur fnctinner tant que (1) au mins un d une série de paquets retransmis atteint sa destinatin avant l expiratin de la temprisatin ; et (2) le canal n est pas rempli de paquets faux et répétés au pint d épuiser les capacités du réseau u de CPU à l un u l autre des pints d extrémité. Même en l absence de ces exigences minimales de perfrmance, IKE est cnçu pur avir des échecs prpres (cmme si le réseau était cassé). Bien que les messages IKEv2 sient prévus pur être curts, ils cntiennent des structures sans limite supérieure de taille (en particulier, les certificats X.509), et IKEv2 lui-même n a as de mécanisme pur fragmenter les grands messages. IP définit un mécanisme pur la fragmentatin des messages UDP sur-dimensinnés, mais la taille maximale de message acceptée varie seln les mises en œuvre. De plus, l utilisatin de la fragmentatin sur IP livre les mises en œuvre aux attaques de déni de service [KPS03]. Finalement, certaines mises en œuvre de NAT et/u pare-feu peuvent blquer les fragments IP. Tutes les mises en œuvre IKEv2 DOIVENT être capables d envyer, recevir, et traiter les messages IKE qui vnt jusqu à 1280 ctets de lng, et elles DEVRAIENT être capables d envyer, recevir, et traiter les messages qui vnt jusqu à 3000 ctets de lng. Les mises en œuvre de IKEv2 DEVRAIENT cnnaître la taille maximale de message UDP acceptée et PEUVENT raccurcir les messages en laissant de côté certains certificats u prpsitins de suite cryptgraphique si cela permet de garder les messages en dessus du maximum. L utilisatin des frmats "Hachage et URL" plutôt que d inclure les certificats dans les échanges lrsque c est pssible peut éviter la plupart des prblèmes. Les mises en œuvre et les cnfiguratins devraient cependant garder présent à l esprit que si les recherches d URL ne snt pssibles qu après l établissement de la SA IPsec, des questins de récurrence purraient empêcher cette technique de fnctinner. 2.1 Utilisatins des temprisateurs de retransmissin Tus les messages existent en paires dans IKE : une demande et une répnse. L établissement d une IKE_SA cnsiste nrmalement en deux paires de demande/répnse. Une fis la IKE_SA établie, une des deux assciatins de sécurité peut initier les demandes à tut mment, et il peut y avir de nmbreuses demandes et répnses "en l air" à tut mment. Mais chaque message est étiqueté cmme demande u répnse, et pur chaque paire demande/répnse une extrémité de l assciatin de sécurité est l initiateur et l autre est le répndant. Pur chaque paire de messages IKE, l initiateur est respnsable de la retransmissin pur le cas ù surviendrait une fin de temprisatin. Le répndant NE DOIT jamais retransmettre une répnse si il n a pas reçu une retransmissin de la demande. Dans ce cas, le répndant DOIT ignrer la demande retransmise sauf dans la mesure ù il déclenche une retransmissin de la répnse. L initiateur DOIT se suvenir de chaque demande jusqu à ce qu il reçive la répnse crrespndante. Le répndant DOIT se suvenir de chaque répnse jusqu à ce qu il reçive une demande dnt le numér de séquence sit supérieur au numér de séquence dans la répnse plus sa taille de fenêtre (vir au paragraphe 2.3). IKE est un prtcle fiable, dans ce sens que l initiateur DOIT retransmettre une demande jusqu à ce qu il reçive une répnse crrespndante OU qu il estime que l assciatin de sécurité IKE a échué et qu il élimine tus les états assciés à la IKE_SA et tutes les CHILD_SA négciées en utilisant cette IKE_SA. 2.2 Utilisatin des numérs de séquence pur l identifiant de message Chaque message IKE cntient un identifiant de message au titre de sn en-tête fixe. Cet identifiant de message est utilisé pur faire crrespndre demandes et répnses, et pur identifier les retransmissins des messages. L identifiant de message est une quantité de 32 bits, qui est zér pur la première demande IKE dans chaque directin. Les messages d établissement initial de IKE_SA sernt tujurs numértés 0 et 1. Chaque pint d extrémité dans l assciatin de sécurité IKE maintient deux identifiants de message "curant" : le prchain à utiliser pur une demande qu il initie et le

9 RFC 4306 page Kaufman & autres prchain qu il s attend à vir dans une demande prvenant de l autre extrémité. Ces cmpteurs s incrémentent lrsque les demandes snt générées et reçues. Les répnses cntiennent tujurs le même identifiant de message que la demande crrespndante. Cela signifie qu après l échange initial, chaque entier n peut apparaître cmme l identifiant de message dans quatre messages distincts : la n ème demande prvenant de l initiateur IKE riginal, la répnse crrespndante, la n ème demande prvenant du répndant IKE riginal, et la répnse crrespndante. Si les deux extrémités rendent très différents les numérs des demandes, les identifiants de message dans les deux directins peuvent être très différents. Il n y a cependant pas d ambiguïté dans les messages, parce que les bits (I)nitiateur et (R)épndant dans l en-tête de message spécifient lequel des quatre messages est un message particulier. Nter que les identifiants de message snt prtégés cryptgraphiquement et furnissent une prtectin cntre la répétitin de message. Dans le cas peu vraisemblable ù les identifiants de message deviendraient trp grands pur tenir sur 32 bits, la IKE_SA DOIT être clse. Le renuvellement de clés d une IKE_SA remet à zér les numérs de séquence. 2.3 Taille de fenêtre pur les demandes en chevauchement Afin de maximiser le débit d IKE, un pint d extrémité IKE PEUT prduire plusieurs demandes avant d btenir une répnse à aucune d entre elles si l autre pint d extrémité a indiqué sa capacité à traiter de telles demandes. Pur simplifier, une mise en œuvre IKE PEUT chisir de traiter les demandes strictement dans l rdre et/u attendre une répnse à une demande avant d en prduire une autre. Certaines règles divent être suivies pur s assurer de l interpérabilité entre des mises en œuvre utilisant des stratégies différentes. Après l établissement d une IKE_SA, l une u l autre extrémité peut initier une u plusieurs demandes. Ces demandes peuvent passer l une après l autre sur le réseau. Un pint d extrémité IKE DOIT être prêt à accepter et traiter une demande alrs qu il a une demande en curs afin d éviter un blcage dans cette situatin. Un pint d extrémité IKE DEVRAIT être prêt à accepter et traiter plusieurs demandes alrs qu il a une demande en curs. Un pint d extrémité IKE DOIT attendre une répnse à chacun de ses messages avant d envyer le message suivant sauf s il a reçu un message Ntify SET_WINDOW_SIZE de sn hmlgue l infrmant que l hmlgue est prêt à maintenir l état pur plusieurs messages en curs afin de permettre un plus grs débit. Un pint d extrémité IKE NE DOIT PAS excéder la taille de fenêtre affichée pur l hmlgue pur les demandes IKE transmises. En d autres termes, si le répndant déclare que sa taille de fenêtre est N, lrsque l initiateur a besin de faire une demande X, il DOIT attendre jusqu à ce qu il ait reçu les répnses à tutes les demandes jusqu à la demande X-N. Un pint d extrémité IKE DOIT garder une cpie de (u être capable de régénérer exactement) chaque demande qu il a envyée jusqu à ce qu il reçive la répnse crrespndante. Un pint d extrémité IKE DOIT garder cpie (u être capable de régénérer exactement) du nmbre de répnses précédentes égal à sa taille de fenêtre déclarée pur le cas ù sa répnse serait perdue et ù l initiateur demanderait sa retransmissin en retransmettant la demande. Un pint d extrémité IKE prenant en charge une taille de fenêtre supérieure à un DEVRAIT être capable de traiter les demandes entrantes qui ne snt pas à leur rdre afin de maximiser les perfrmances en vue de défaillances du réseau u de rérdnnancement des paquets. 2.4 Synchrnisatin d état et fin de temprisatin de cnnexin Un pint d extrémité IKE peut ublier tus ses états assciés à une IKE_SA et la cllectin des CHILD_SA crrespndantes à tut mment. C est le cmprtement prévu dans le cas de défaillance et redémarrage d un pint d extrémité. Il est imprtant, lrsque un pint d extrémité a une défaillance u réinitialise sn état, que l autre pint d extrémité détecte ces cnditins et ne cntinue pas à gâcher de la bande passante en envyant des paquets sur des SA éliminées et les vir tmber dans un tru nir. Cmme IKE est cnçu pur fnctinner en dépit des attaques de déni de service (DS) prvenant du réseau, un pint d extrémité NE DOIT PAS cnclure que l autre pint d extrémité est défaillant sur la base d infrmatins d acheminement (par exemple, de messages ICMP) u de messages IKE qui arrivent sans prtectin cryptgraphique (par exemple, messages Ntify se plaignant de SPI incnnus). Un pint d extrémité ne DOIT cnclure que l autre pint d extrémité a une défaillance que lrsque des tentatives répétées de le cntacter snt restées sans répnse pendant une péride de temprisatin u lrsque une ntificatin INITIAL_CONTACT prtégée cryptgraphiquement est reçue sur une IKE_SA différente sur la même identité authentifiée. Un pint d extrémité DEVRAIT suspecter que l autre pint d extrémité a une défaillance sur la base des infrmatins d acheminement et initier une demande pur vir si l autre pint d extrémité est vivant. Pur vérifier si l autre côté est tujurs en vie, IKE spécifie un message INFORMATIONAL vide qui exige

10 RFC 4306 page Kaufman & autres (cmme tutes les demandes IKE) un accusé de réceptin (nter que dans le cntexte d une IKE_SA, un message "vide" cnsiste en un en-tête IKE suivi par une charge utile Encrypted qui ne cntient pas de charge utile). Si un message prtégé cryptgraphiquement a été reçu récemment de l autre côté, les ntificatins nn prtégées PEUVENT être ignrées. Les mises en œuvre DOIVENT limiter le débit auquel elles entreprennent des actins sur la base de messages nn prtégés. Le nmbre des répétitins et la durée des temprisatins ne snt pas traitées dans la présente spécificatin parce qu elles n affectent pas l interpérabilité. Il est suggéré que les messages sient retransmis au mins une duzaine de fis sur une péride de plusieurs minutes avant d abandnner une SA, mais des envirnnements différents peuvent exiger des règles différentes. Pur être un bn cityen sur le réseau, les temps entre les retransmissins DOIVENT avir une crissance expnentielle pur éviter de nyer le réseau et rendre pire une situatin d encmbrement existante. Si il y a seulement eu du trafic srtant sur tutes les SA assciées à une IKE_SA, il est essentiel de cnfirmer que l autre pint d extrémité est tujurs en vie pur éviter les trus nirs. Si aucun message prtégé cryptgraphiquement n a été reçu sur une IKE_SA u aucune de ses CHILD_SA récemment, le système dit faire une vérificatin de vie afin de prévenir l envi de messages sur un hmlgue mrt. La réceptin d un message prtégé cryptgraphiquement frais sur une IKE_SA u une de ses CHILD_SA assure de la vie de la IKE_SA et de tutes ses CHILD_SA. Nter que cela fait peser des exigences sur les mdes de défaillance d un pint d extrémité IKE. Une mise en œuvre NE DOIT PAS cntinuer d envyer sur une SA si quelque défaillance l empêche de recevir sur tutes les SA assciées. Si les CHILD_SA peuvent avir des défaillances indépendamment les unes des autres sans que la IKE_SA assciée sit capable d envyer un message Delete, elles DOIVENT alrs être négciées par des IKE_SA séparées. Il y a une attaque de déni de service cntre l initiateur d une IKE_SA qui peut être évitée si l initiateur prend les bnnes précautins. Cmme les deux premiers messages d un établissement de SA ne snt pas prtégés cryptgraphiquement, un attaquant purrait répndre au message de l initiateur avant le répndant authentique et empisnner la tentative d établissement de la cnnexin. Pur empêcher cela, l initiateur PEUT vulir accepter plusieurs répnses à sn premier message, traiter chacune cmme ptentiellement légitime, lui répndre, puis éliminer tutes les cnnexins semi uvertes invalides lrsqu il reçit une répnse valide prtégée cryptgraphiquement à l une de ses demandes. Une fis qu une répnse cryptgraphiquement valide est reçue, tutes les répnses subséquentes devraient être ignrées, qu elles sient u nn cryptgraphiquement valides. Nter qu avec ces règles, il n y a pas de raisn de négcier et se mettre d accrd sur la durée de vie d une SA. Si IKE suppse que le partenaire est mrt, sur la base d un manque répété d accusé de réceptin à un message IKE, la SA IKE et tutes les CHILD_SA établies à travers cette IKE_SA snt supprimées. Un pint d extrémité IKE peut à tut mment supprimer les CHILD_SA inactives pur récupérer des ressurces utilisées pur maintenir leur état. Si un pint d extrémité IKE chisit de supprimer des CHILD_SA, il DOIT envyer des charges utiles Delete à l autre extrémité en lui ntifiant la suppressin. Il PEUT de la même façn mettre fin à la temprisatin de la IKE_SA. Clre la IKE_SA clôt implicitement tutes les CHILD_SA assciées. Dans ce cas, un pint d extrémité IKE DEVRAIT envyer une charge utile Delete indiquant qu il a fermé la IKE_SA. 2.5 Numérs de versin et rétr cmpatibilité Le présent dcument décrit la versin 2.0 de IKE, ce qui signifie que le numér de versin majeur est 2 et le numér de versin mineur est zér. Il est vraisemblable que certaines mises en œuvre vudrnt accepter les deux versins 1.0 et 2.0, et à l avenir, d autres versins. Le numér de versin majeur ne devrait être incrémenté que si les frmats de paquet u les actins requises nt changé à tel pint qu un nœud de versin plus ancienne ne serait pas capable d interpérer avec un nœud de versin plus récente si il devait simplement ignrer les champs qu il ne cmprend pas et entreprendre les actins spécifiées dans l ancienne spécificatin. Le numér de versin mineur indique de nuvelles capacités, et DOIT être ignré par un nœud ayant un plus petit numér de versin mineur, mais utilisé pur des besins d infrmatin par le nœud ayant le plus grand numér de versin mineur. Par exemple, il peut indiquer la capacité à traiter un message de ntificatin nuvellement défini. Le nœud avec le plus grand numér de versin mineur nterait simplement que sn crrespndant ne sera pas capable de cmprendre ce message et dnc, ne l enverra pas. Si un pint d extrémité reçit un message avec un plus frt numér de versin majeur, il DOIT abandnner le message et DEVRAIT envyer un message de ntificatin nn authentifié cntenant le plus frt numér de versin qu il prend en charge. Si un pint d extrémité accepte la versin majeure n, et la versin majeure m, il DOIT accepter tutes les versins entre n et m. Si il reçit un message avec une versin majeure qu il accepte, il DOIT répndre avec ce numér de versin. Afin d empêcher deux nœuds de se prendre à crrespndre sur un numér de versin majeure inférieur au maximum qu ils acceptent tus deux, IKE a un fanin qui indique qu un nœud est capable de cmmuniquer dans un numér de versin majeur supérieur.

11 RFC 4306 page Kaufman & autres Et dnc, le numér de versin majeur dans l en-tête IKE indique le numér de versin du message, et nn le plus frt numér de versin qu accepte l émetteur. Si l initiateur est capable de traiter les versins n, n+1, et n+2, et si le répndant est capable de traiter les versins n et n+1, il vnt négcier le traitement de n+1, et l initiateur va mettre le fanin qui indique sa capacité à traiter une versin supérieure. Si par erreur (peut-être à cause de l envi de messages errnés par un attaquant actif) il négcient la versin n, tus deux vnt alrs remarquer que l autre côté peut accepter un numér de versin plus élevé, et ils DOIVENT rmpre la cnnexin et se recnnecter en utilisant la versin n+1. Nter que IKEv1 ne suit pas ces règles, parce qu il n y a pas de myen en v1 de nter qu n est capable de traiter un numér de versin plus élevé. Aussi, un attaquant actif peut trmper deux nœud capables de traiter la v2 pur les faire cmmuniquer en v1. Lrsqu un nœud capable de v2 négcie en se rabattant sur la v1, il DEVRAIT nter le fait dans ses enregistrements de jurnalisatin. Pur préserver la rétr cmpatibilité, tus les champs marqués RESERVED DOIVENT être mis à zér par une mise en œuvre de versin 2.0 et leur cntenu DOIT être ignré par une mise en œuvre de versin 2.0 ("être cnservateur dans ce que vus envyez et libéral dans ce que vus recevez"). De cette façn, les futures versins du prtcle purrnt utiliser ces champs d une manière dnt n peut garantir qu elle sera ignrée par les mises en œuvre qui ne les cmprennent pas. De même, les types de charge utile qui ne snt pas définis snt réservés pur une utilisatin future. IKEv2 ajute un fanin "critique" à chaque en-tête de charge utile pur plus de suplesse dans la rétr cmpatibilité. Si le fanin critique est mis, et si le type de charge utile n est pas recnnu, le message DOIT être rejeté et la répnse à la demande IKE qui cntient cette charge utile DOIT inclure une charge utile Ntify UNSUPPORTED_CRITICAL_PAYLOAD qui indique qu une charge utile critique nn prise en charge a été incluse. Si le fanin critique n est pas mis et si le type de charge utile n est pas accepté, cette charge utile DOIT être ignrée. Bien que de nuveaux types de charge utile puissent être ajutés à l avenir et puissent paraître entrelacés dans les champs définis par la présente spécificatin, les mises en œuvre DOIVENT envyer les charges utiles définies dans la présente spécificatin dans l rdre indiqué sur les figures de la sectin 2 et les mises en œuvre DEVRAIENT rejeter cmme invalide un message ayant ces charges utiles dans tut autre rdre. 2.6 Témins Le terme "ckie" (témin) tire sn rigine de Phturis de Karn et Simpsn [RFC2522], prpsitin ancienne de gestin de clés avec IPsec, et il a persisté. L assciatin de sécurité Internet et le prtcle de gestin de clés (ISAKMP) [RFC2408] nt fixé un en-tête de message qui inclut deux champs de huit ctets intitulés "ckies", et cette syntaxe est utilisée aussi bien par IKEv1 que IKEv2 bien que dans IKEv2 ils sient désignés cmme le SPI IKE et qu il y ait un nuveau champ distinct dans une charge utile Ntify qui cntient le témin. Les deux champs initiaux de huit ctets dans l en-tête snt utilisés cmme identifiant de cnnexin au début des paquets IKE. Chaque pint d extrémité chisit un des deux SPI et DEVRAIT les chisir pur être les identifiants uniques d une IKE_SA. Une valeur de SPI de zér est spéciale et indique que la valeur de SPI distante n est pas encre cnnue de l envyeur. À la différence de ESP et AH ù seul le SPI du receveur apparaît dans l en-tête d un message, dans IKE, le SPI de l envyeur est aussi envyé dans chaque message. Cmme le SPI chisi par l initiateur riginal de la IKE_SA est tujurs envyé en premier, un pint d extrémité avec plusieurs IKE_SA uvertes qui veut truver la IKE_SA apprpriée en utilisant le SPI qu il a allué dit regarder le bit de fanin I(nitiateur) dans l en-tête pur déterminer si il a allué les huit premiers u les huit secnds ctets. Dans le premier message d un échange initial IKE, l initiateur ne cnnaîtra pas la valeur du SPI du répndant et mettra dnc ce champ à zér. On s attend à une attaque cntre IKE à partir de l épuisement d état et de CPU, dans laquelle la cible est nyée sus des demandes d initiatin de sessin venant de fausses adresses IP. Cette attaque peut être rendue mins efficace si une mise en œuvre d un répndant utilise une CPU minimale et n envie aucun état à une SA jusqu à ce qu il sache que l initiateur peut recevir des paquets à l adresse d ù il affirme qu il les envie. Pur ce faire, un répndant DEVRAIT -- quand il détecte un grand nmbre de IKE_SA demi-uvertes -- rejeter les messages initiaux IKE jusqu à ce qu ils cntiennent une charge utile Ntify du type COOKIE. Il DEVRAIT à la place envyer un message IKE nn prtégé en répnse et inclure une charge utile Ntify COOKIE avec les dnnées du témin à returner. Les initiateurs qui reçivent de telles répnses DOIVENT réessayer le IKE_SA_INIT avec une charge utile Ntify du type COOKIE cntenant les dnnées du témin furni par le répndant cmme première charge utile et tutes les autres charges utiles inchangées. L échange initial sera alrs cmme suit :

12 RFC 4306 page Kaufman & autres Initiateur Répndant HDR(A,0), SAi1, KEi, Ni -HDR(A,0), N(COOKIE) HDR(A,0), N(COOKIE), SAi1, KEi, Ni HDR(A,B), SAr1, KEr, Nr, [CERTREQ] HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} HDR(A,B), SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr} Les deux premiers messages n affectent aucun état d initiateur u de répndant sauf pur la cmmunicatin du témin. En particulier, les numérs de séquence de message dans les quatre premiers messages sernt tus à zér et les numérs de séquence de message dans les deux derniers messages sernt à un. 'A' est le SPI allué par l initiateur, alrs que 'B' est le SPI allué par le répndant. Une mise en œuvre IKE DEVRAIT mettre en œuvre la génératin du témin de répndant de telle façn qu elle n exige la sauvegarde d aucun état pur recnnaître la validité de sn témin lrsque arrive le secnd message IKE_SA_INIT. Les algrithmes exacts et la syntaxe qu ils utilisent pur générer les témins n affectent pas l interpérabilité et dnc ne snt pas spécifiés ici. Ci-après figure un exemple de la façn dnt un pint d extrémité purrait utiliser des témins pur mettre en œuvre une prtectin limitée cntre le déni de service. Une bnne façn de le faire est de régler le témin du répndant à : Ckie = <VersinIDfSecret> Hash(Ni IPi SPIi <secret>) ù <secret> est un secret généré de façn aléatire cnnu du seul répndant et changé péridiquement et indique l enchaînement. <VersinIDfSecret> devrait être changé à chaque fis que <secret> est régénéré. Le témin peut être recalculé lrsque le IKE_SA_INIT arrive pur la secnde fis et est cmparé au témin reçu dans le message reçu. Si il y a crrespndance, le répndant sait que le témin a été généré depuis le dernier changement du <secret> et que IPi dit être le même que l adresse de surce qu il a vu la première fis. Incrprer SPIi dans le calcul garantit que si plusieurs IKE_SA snt en curs d établissement en parallèle, elles aurnt tutes des témins différents (en suppsant que l initiateur chisisse un SPLi unique pur elles tutes). Incrprer Ni dans le hachage garantit qu un attaquant qui ne vit que le message 2 ne peut pas réussir à faire un faux message 3. Si n chisit une nuvelle valeur pur <secret> alrs qu n est engagé dans le prcessus d initialisatin d une nuvelle cnnexin, un IKE_SA_INIT peut être returné avec autre chse que le <VersinIDfSecret> en curs. Dans ce cas le répndant PEUT rejeter le message en envyant une autre répnse avec un nuveau témin u il PEUT garder la vieille valeur de <secret> en réserve pendant un bref instant et accepter les témins calculés à partir de l un u de l autre. Le répndant NE DEVRAIT PAS accepter indéfiniment des témins après le changement du <secret>, car cela mettrait en échec une partie de la prtectin cntre le déni de service. Le répndant DEVRAIT changer la valeur de <secret> fréquemment, et tut spécialement s il est sumis à des attaques. 2.7 Négciatin d algrithme cryptgraphique Le type de charge utile cnnu cmme "SA" indique une prpsitin d un ensemble de chix de prtcles IPsec (IKE, ESP, et/u AH) pur la SA ainsi que des algrithmes cryptgraphiques assciés à chaque prtcle. Une charge utile SA cnsiste en une u plusieurs prpsitins. Chaque prpsitin cmprte un u plusieurs prtcles (généralement un seul). Chaque prtcle cntient une u plusieurs transfrmatins -- chacune spécifiant un algrithme cryptgraphique. Chaque transfrmatin cntient zér, un u plusieurs attributs (les attributs ne snt nécessaires que si l identifiant de transfrmatin ne spécifie pas cmplètement l algrithme cryptgraphique). Cette structure hiérarchique a été cnçue pur cder efficacement les prpsitins de suites cryptgraphiques lrsque le nmbre de suites prises en charge est imprtant parce que plusieurs valeurs snt acceptables pur plusieurs transfrmatins. Le répndant DOIT chisir une seule suite, qui PEUT être tut sus-ensemble de la prpsitin SA suivant les règles ci-dessus : Chaque prpsitin cntient un u plusieurs prtcles. Si une prpsitin est acceptée, la répnse SA DOIT cntenir les mêmes prtcles dans le même rdre que la prpsitin. Le répndant DOIT accepter une seule prpsitin u les rejeter tutes et returner une erreur. (Par exemple : si une seule prpsitin cntient ESP et AH et si cette prpsitin est acceptée, ESP et AH DOIVENT tus deux être acceptés. Si ESP et AH snt inclus dans des prpsitins séparées, le répndant DOIT accepter une seule d entre elles).

13 RFC 4306 page Kaufman & autres Chaque prpsitin de prtcle IPsec cntient une u plusieurs transfrmatins. Chaque transfrmatin cntient un type transfrm. La suite cryptgraphique acceptée DOIT cntenir exactement une transfrmatin de chaque type incluse dans la prpsitin. Par exemple: si une prpsitin ESP inclut les transfrmatins ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256, AUTH_HMAC_MD5, et AUTH_HMAC_SHA, la suite acceptée DOIT cntenir une des transfrmatins ENCR_ et une des transfrmatins AUTH_. Et dnc, six cmbinaisns snt acceptables. Cmme l initiateur envie sa valeur Diffie-Hellman dans IKE_SA_INIT, il dit deviner le grupe Diffie-Hellman que le répndant va chisir dans sa liste de grupes acceptés. Si l initiateur devine mal, le répndant répndra par une charge utile Ntify de type INVALID_KE_PAYLOAD indiquant le grupe chisi. Dans ce cas, l initiateur DOIT réessayer le IKE_SA_INIT avec le grupe Diffie-Hellman crrigé. L initiateur DOIT à nuveau prpser l'ensemble cmplet de suites cryptgraphiques acceptables parce que le message de rejet était nn authentifié et autrement, un attaquant actif purrait trmper les pints d extrémité en négciant une suite plus faible que la plus frte préférée par tus les deux. 2.8 Renuvellement des clés Les assciatins de sécurité IKE, ESP, et AH utilisent des clés secrètes qui ne DEVRAIENT être utilisées que pur une durée limitée et pur prtéger une quantité de dnnées limitée. Cela limite la durée de vie de l assciatin de sécurité tute entière. Lrsque la durée de vie d une assciatin de sécurité expire, celle-ci NE DOIT PLUS être utilisée. Si il y a une demande, de nuvelles assciatins de sécurité PEUVENT être établies. Le nuvel établissement d assciatins de sécurité pur prendre la place de celles qui snt arrivées à expiratin est appelé "renuvellement de clés" (rekeying). Pur permettre des mises en œuvre IPsec minimales, la capacité à renuveler les clés des SA sans redémarrer tute la IKE_SA est facultatif. Une mise en œuvre PEUT refuser tutes les demandes CREATE_CHILD_SA au sein d une IKE_SA. Si une SA est arrivée à expiratin u est sur le pint d arriver à expiratin et que les tentatives de renuvellement de clés en utilisant les mécanismes décrits ici échuent, une mise en œuvre DOIT clre la IKE_SA et tutes CHILD_SA assciées et PEUT ensuite en cmmencer de nuvelles. Les mises en œuvre DEVRAIENT prendre en charge le renuvellement de clés des SA en place, car faire ainsi ffre de meilleures perfrmances et va vraisemblablement réduire le nmbre de paquets perdus durant la transitin. Pur renuveler les clés d une CHILD_SA au sein d une IKE_SA existante, il faut créer une nuvelle SA équivalente (vir au paragraphe 2.17 ci-dessus) et quand la nuvelle est établie, supprimer l ancienne. Pur renuveler les clés d une IKE_SA, établir une nuvelle IKE_SA équivalente (vir au paragraphe 2.18 ci-dessus) avec l hmlgue avec qui la vieille IKE_SA est partagée en utilisant un CREATE_CHILD_SA au sein de la IKE_SA existante. Une IKE_SA ainsi créée hérite de tutes les CHILD_SA de la IKE_SA riginale. On utilise la nuvelle IKE_SA pur tus les messages de cmmandes nécessaires pur maintenir les CHILD_SA créées par la vieille IKE_SA, et supprimer celle-ci. La charge utile Delete pur se supprimer elle-même DOIT être la dernière demande envyée sur une IKE_SA. Les SA DEVRAIENT avir un renuvellement de clés pr-actif, c est-à-dire que la nuvelle SA devrait être établie avant que l arrivée à expiratin de la vieille ne la rende inutilisable. Suffisamment de temps devrait s éculer entre le mment ù la nuvelle SA est établie et celui ù l ancienne devient inutilisable afin que le trafic puisse être basculé sur la nuvelle SA. Une différence entre IKEv1 et IKEv2 est que dans IKEv1 les durées de vie de SA étaient négciées. Dans IKEv2, chaque extrémité de la SA est chargée de mettre en applicatin sa prpre plitique de durée de vie sur les SA et de renuveler les clés de la SA lrsque c est nécessaire. Si les deux extrémités nt des plitiques de durée de vie différentes, l extrémité qui a la durée de vie la plus curte va tujurs être celle qui demande le renuvellement de clés. Si un faisceau de SA a été inactif pendant un lng mment et si un pint d extrémité n initie pas SA en l absence de trafic, le pint d extrémité PEUT chisir de clre la SA au lieu de renuveler ses clés lrsque sa durée de vie arrive à expiratin. Il DEVRAIT le faire si il n y a pas eu de trafic depuis le dernier renuvellement de clés de la SA. Si les deux extrémités nt la même plitique de durée de vie, il est pssible que tutes deux initient un renuvellement de clés en même temps (d ù résulternt des SA redndantes). Pur réduire la prbabilité de cet événement, la temprisatin des demandes de renuvellement de clés DEVRAIT être aléatire (retardée d une durée aléatire après avir remarqué le besin de renuvellement de clés). Cette frme de renuvellement de clés peut temprairement résulter en plusieurs SA similaires entre les mêmes paires de nœuds. Lrsqu il y a deux SA éligibles pur recevir des paquets, un nœud DOIT accepter les paquets entrants par l une et l autre SA. Si des SA redndantes snt créées malgré une telle cllisin, la SA créée avec le plus faible des quatre nms ccasinnels utilisés dans les deux échanges DEVRAIT être fermée par le pint d extrémité qui l a créée. Nter que IKEv2 permet délibérément des SA parallèles avec les mêmes sélecteurs de trafic entre des pints d extrémité

14 RFC 4306 page Kaufman & autres cmmuns. Un des bjets de ce cmprtement est de prendre en charge la différence de qualité de service (QS) du trafic parmi les SA (Vir les [RFC2474], [RFC2475], et le paragraphe 4.1 de la [RFC2983]). Et dnc, à la différence de IKEv1, la cmbinaisn des pints d extrémité et des sélecteurs de trafic peut ne pas identifier de façn univque une SA entre ces pints d extrémité, aussi l heuristique de renuvellement de clés de IKEv1 cnsistant à supprimer les SA sur la base de la duplicatin des sélecteurs de trafic NE DEVRAIT PAS être utilisée. Le nœud qui a initié la SA à clés renuvelée survivante DEVRAIT supprimer la SA remplacée après que la nuvelle a été établie. Il y a des fenêtres de temprisatin en particulier en présence de paquets perdus ù les pints d extrémité peuvent ne pas se mettre d accrd sur l état d une SA. Le répndant à un message CREATE_CHILD_SA DOIT être prêt à accepter des messages sur une SA avant d envyer sa répnse à la demande de créatin, afin qu il n y ait pas d ambiguïté pur l initiateur. L initiateur PEUT cmmencer à envyer sur une SA aussitôt qu il a traité la répnse. L initiateur ne peut cependant pas recevir sur une SA nuvellement créée jusqu à ce qu il ait reçu et traité la répnse à sa demande CREATE_CHILD_SA. Cmment le répndant va-t-il savir quand il y a accrd pur qu il envie sur la SA nuvellement créée? Du pint de vue de la crrectin technique et de l interpérabilité, le répndant PEUT cmmencer à envyer sur une SA aussitôt qu il envie sa répnse à la demande CREATE_CHILD_SA. Dans certaines situatins, cela peut cependant avir pur résultat que des paquets sient abandnnés sans nécessité, aussi une mise en œuvre PEUT vulir différer un tel envi. Le répndant peut être sûr que l initiateur est prêt à recevir des messages sur une SA si (1) il a reçu un message cryptgraphiquement valide sur une nuvelle SA, u (2) la nuvelle SA renuvelle les clés d une SA existante et il reçit une demande IKE de clre la SA remplacée. Lrsqu il renuvelle les clés d une SA, le répndant DEVRAIT cntinuer à envyer des messages sur la vieille SA jusqu à ce qu un de ces événements survienne. Lrs de l établissement d une nuvelle SA, le répndant PEUT différer l envi de messages sur une nuvelle SA jusqu à ce qu il en reçive une u qu une fin de temprisatin survienne. Si un initiateur reçit un message sur une SA pur laquelle il n a pas reçu de répnse à sa demande CREATE_CHILD_SA, il DEVRAIT interpréter cela cmme une perte vraisemblable de paquet et retransmettre sa demande CREATE_CHILD_SA. Un initiateur PEUT envyer un message factice sur une SA nuvellement créée si il n a pas de message en file d attente afin d assurer au répndant que l initiateur est prêt à recevir des messages. 2.9 Négciatin de sélecteur de trafic Lrsqu un paquet IP est reçu par un sus-système IPsec cnfrme à la RFC4301 et crrespnd à un sélecteur "prtect" dans sa base de dnnées de plitique de sécurité (SPD, Security Plicy Database) le sus-système DOIT prtéger ce paquet avec IPsec. Quand il n existe pas encre de SA, il appartient à IKE de la créer. La maintenance de la SPD d un système srt du dmaine d applicatin de IKE (vir [RFC2367] pur un exemple de prtcle) bien que certaines mises en œuvre puissent mettre à jur leur SPD en cnnexin avec le fnctinnement de IKE (pur un exemple de scénari, vir au paragraphe 1.1.3). Les charges utiles de sélecteur de trafic (TS, Traffic Selectr) permettent aux pints d extrémité de cmmuniquer certaines des infrmatins prvenant de leur SPD à leurs hmlgues. Les charges utiles de TS spécifient les critères de chix des paquets qui sernt transmis sur la SA nuvellement établie. Cela peut servir de vérificatin de chérence dans certains scénaris pur s assurer que les SPD snt chérentes. Dans d autres, cela sert de guide à la mise à jur dynamique de la SPD. Deux charges utiles de TS apparaissent dans chaque message dans l échange qui crée une paire de CHILD_SA. Chaque charge utile de TS cntient un u plusieurs sélecteurs de trafic. Chaque sélecteur de trafic cnsiste en une gamme d adresses (IPv4 u IPv6), une gamme d'accès, et un identifiant de prtcle IP. À l appui du scénari décrit au paragraphe 1.1.3, un initiateur peut demander que le répndant allue une adresse IP et dise à l initiateur ce qu elle est. IKEv2 permet au répndant de chisir un sus-ensemble du trafic prpsé par l initiateur. Cela peut arriver quand les cnfiguratins des deux pints d extrémité snt en curs de mise à jur mais qu une seule extrémité a reçu les nuvelles infrmatins. Cmme les deux pints d extrémité peuvent être cnfigurés par des persnnes différentes, l incmpatibilité peut persister pendant un assez lng mment même en l absence d erreurs. Cela permet aussi des cnfiguratins intentinnellement différentes, cmme quand une extrémité est cnfigurée pur tunneler tutes les adresses et dépend de l autre extrémité pur avir la liste mise à jur. La première des deux charges utiles de TS est appelée TSi (sélecteur initiateur de trafic). La secnde est appelée TSr (Sélecteur de trafic répndant). TSi spécifie l adresse de surce du trafic transmis de (u l adresse de destinatin du trafic transmis à) l initiateur de la paire de CHILD_SA. TSr spécifie l adresse de destinatin du trafic transmis au (u l adresse de surce du trafic transmis du) répndant de la paire CHILD_SA. Par exemple, si l initiateur riginal demande la créatin d une paire de CHILD_SA, et suhaite tunneler tut le trafic prvenant du sus-réseau * du côté de l initiateur du

15 RFC 4306 page Kaufman & autres sus-réseau * du côté du répndant, l initiateur devra inclure un seul sélecteur de trafic dans chaque charge utile de TS. TSi spécifiera la gamme d adresses ( ) et TSr spécifiera la gamme d adresses ( ). En suppsant que la prpsitin est acceptable pur le répndant, il renverra des charges utiles de TS identiques. (Nte : La gamme d adresses IP * a été réservée pur être utilisée dans des exemples dans les RFC et dcuments similaires. Le présent dcument avait besin de deux gammes de ce genre, et utilise dnc aussi *. Ceci ne devrait pas être cnfndu avec une adresse réelle.) Le répndant peut rétrécir les chix en sélectinnant un sus-ensemble du trafic, par exemple en éliminant u en réduisant la gamme d un u plusieurs membres de l ensemble des sélecteurs de trafic, purvu que l ensemble ne devienne pas l ensemble NUL. Il est pssible que la plitique du répndant cntienne plusieurs gammes plus petites, tutes mises en applicatin par le sélecteur de trafic de l initiateur, et que la plitique du répndant sit que chacune de ces gammes sit envyée sur une SA différente. En pursuivant l exemple ci-dessus, le répndant purrait avir une plitique de tunneler ces adresses de et vers l initiateur, mais purrait exiger que chaque paire d adresse sit sur une CHILD_SA négciée séparément. Si l initiateur a généré sa demande en répnse à un paquet entrant de à , il n y aura aucun myen pur le répndant de déterminer quelle paire d adresses devrait être incluse dans ce tunnel, et il faudra qu il le devine u rejette la demande avec un statut de SINGLE_PAIR_REQUIRED. Pur permettre au répndant de chisir la gamme apprpriée dans ce cas, si l initiateur a demandé la SA à cause d un paquet de dnnées, l initiateur DEVRAIT inclure cmme premier sélecteur de trafic dans chacun de TSi et TSr un sélecteur de trafic très spécifique cmprtant les adresses qui étaient dans le paquet qui a déclenché la demande. Dans l exemple, l initiateur inclurait dans TSi deux sélecteurs de trafic : le premier cntiendrait la gamme d adresses ( ) l'accès de surce et le prtcle IP venant du paquet, et le secnd cntiendrait ( ) avec tus les accès et prtcles IP. L initiateur inclurait de la même manière deux sélecteurs de trafic dans TSr. Si la plitique du répndant ne lui permet pas d accepter l ensemble entier des sélecteurs de trafic de la demande de l initiateur, mais lui permet d accepter le premier sélecteur de TSi et TSr, le répndant DOIT alrs réduire les sélecteurs de trafic à un sus-ensemble qui inclut les premiers chix de l initiateur. Dans ntre exemple, le répndant purrait répndre avec TSi à ( ) avec tus les accès et prtcles IP. Si l initiateur crée la paire de CHILD_SA en dehrs d une répnse à l arrivée d un paquet, mais plutôt, disns, au démarrage, il peut alrs n y avir pas d adresses spécifiques que préfère plus qu un autre l initiateur pur le tunnel initial. Dans ce cas, les premières valeurs dans TSi et TSr PEUVENT être des gammes plutôt que des valeurs spécifiques, et le répndant chisit un sus-ensemble des TSi et TSr de l initiateur qui sient acceptables. Si plus d un sus-ensemble est acceptable mais que leur unin ne l est pas, le répndant DOIT accepter un sus-ensemble et PEUT inclure une charge utile Ntify de type ADDITIONAL_TS_POSSIBLE pur indiquer que l initiateur peut vulir essayer encre. Ce cas ne surviendra que lrsque l initiateur et le répndant nt des cnfiguratins différentes les unes des autres. Si l initiateur et le répndant snt d accrd sur la granularité des tunnels, l initiateur ne demandera jamais un tunnel plus large que celui qu acceptera le répndant. De tels désaccrds de cnfiguratin DEVRAIENT être enregistrés dans un jurnal d erreurs Nms ccasinnels Les messages IKE_SA_INIT cntiennent chacun un nm ccasinnel (nnce). Ces nms ccasinnels snt utilisés cmme entrées aux fnctins cryptgraphiques. La demande CREATE_CHILD_SA et la répnse CREATE_CHILD_SA cntiennent aussi des nms ccasinnels. Ces nms ccasinnels snt utilisés pur ajuter de la fraîcheur à la technique de déductin de clés utilisée pur btenir des clés pur une CHILD_SA, et pur assurer la créatin de bits pseud-aléatires frts à partir de la clé Diffie-Hellman. Les nms ccasinnels utilisés dans IKEv2 DOIVENT être chisis de façn aléatire, DOIVENT être d une taille d au mins 128 bits, et DOITVENT être au mins de la mitié de la taille de la clé de la prf négciée ("prf" se réfère à la fnctin "pseud aléatire", un des algrithmes cryptgraphiques négciés dans l échange IKE.) Si la même surce de nmbres aléatires est utilisée à la fis pur les clés et les nms ccasinnels, il faut veiller à s assurer que ce dernier usage ne cmprmet pas le précédent Adresse et agilité d'accès IKE fnctinne sur les accès UDP 500 et 4500, et établit implicitement des assciatins ESP et AH pur les mêmes adresses IP que celles sur lesquelles il fnctinne. Les adresses et accès IP dans l en-tête externe ne snt cependant pas eux-mêmes prtégés cryptgraphiquement, et IKE est cnçu pur fnctinner même à travers des bîtes de traductin d adresse réseau (NAT, Netwrk Address Translatin). Une mise en œuvre DOIT accepter les demandes entrantes même si l'accès de surce n est pas 500 u 4500, et DOIT répndre à l adresse et à l'accès d ù la demande a été reçue. Elle DOIT

16 RFC 4306 page Kaufman & autres spécifier l adresse et l'accès auxquels la demande a été reçue cmme adresse de surce et accès dans la répnse. IKE fnctinne de façn identique sur IPv4 u IPv Réutilisatin des expnentielles de Diffie-Hellman IKE génère du matériel de clés en utilisant un échange Diffie-Hellman éphémère afin d btenir la prpriété de "secret de transmissin parfait". Cela signifie qu une fis qu une cnnexin est clse et que ses clés crrespndantes snt ubliées, même quelqu un qui aurait enregistré tutes les dnnées de la cnnexin et btenu l accès à tutes les clés à lng terme des deux pints d extrémité ne purrait pas recnstruire les clés utilisées pur prtéger la cnversatin sans effectuer une recherche en frce (exhaustive) de l espace de clés de la sessin. Réaliser un secret de transmissin parfait exige que lrsqu une cnnexin est clse, chaque pint d extrémité DOIVE ublier nn seulement les clés utilisées par la cnnexin mais aussi tute infrmatin qui purrait être utilisée pur recalculer ces clés. En particulier, il DOIT ublier les secrets utilisés dans le calcul Diffie-Hellman et tut état qui peut persister dans le générateur de nmbres pseud-aléatires qui purrait être utilisé pur recalculer les secrets Diffie- Hellman. Cmme le calcul des expnentielles Diffie-Hellman est cûteux en calcul, un pint d extrémité peut truver avantageux de réutiliser ces expnentielles pur plusieurs établissements de cnnexin. Il y a plusieurs stratégies raisnnables pur faire cela. Un pint d extrémité purrait ne chisir une nuvelle expnentielle que péridiquement bien qu il puisse en résulter un secret de transmissin mins parfait si une cnnexin dure mins que la durée de vie de l expnentielle. Ou il purrait garder trace des expnentielles utilisées pur chaque cnnexin et ne supprimer les infrmatins assciées à l expnentielle que lrsque la cnnexin crrespndante est clse. Cela permettrait que l expnentielle sit réutilisée sans perdre le secret de transmissin parfait pur le prix du maintient de plus d états. Les décisins quant à la réutilisatin des expnentielles Diffie-Hellman et du mment de le faire snt privées au sens ù cela n affectera pas l interpérabilité. Une mise en œuvre qui réutilise les expnentielles PEUT chisir de se suvenir des expnentielles utilisées par l autre pint d extrémité dans les échanges passés, et si l un d eux est réutilisé, pur éviter la deuxième mitié du calcul Génératin du matériel de clés Dans le cntexte de IKE_SA, quatre algrithmes cryptgraphiques snt négciés : un algrithme de chiffrement, un algrithme de prtectin d intégrité, un grupe Diffie-Hellman, et une fnctin pseud-aléatire (prf, pseud-randm functin). La fnctin pseud-aléatire est utilisée pur la cnstructin du matériel de clés pur tus les algrithmes cryptgraphiques utilisés dans la IKE_SA et les CHILD_SA. On suppse que chaque algrithme de chiffrement et de prtectin d intégrité utilise une clé de taille fixe et que chaque valeur chisie de façn aléatire de cette taille fixe peut servir de clé apprpriée. Pur les algrithmes qui acceptent une lngueur de clé variable, une taille de clé fixe DOIT être spécifiée au titre de la transfrmée cryptgraphique négciée. Pur les algrithmes pur lesquels tutes les valeurs ne snt pas des clés valides (cmme DES u 3DES avec parité de clés) l algrithme par lequel les clés snt déduites de valeurs arbitraires DOIT être spécifié par la transfrmatin cryptgraphique. Pur les fnctins de prtectin d intégrité fndées sur le hachage de cde d authentificatin de message (HMAC, Hashed Message Authenticatin Cde) la taille de clé fixe est la taille du résultat de la fnctin de hachage susjacente. Lrsque la fnctin prf prend une clé de lngueur variable, des dnnées de lngueur variable, et prduit un résultat de lngueur fixe (par exemple, en utilisant HMAC) les frmules du présent dcument s appliquent. Lrsque la clé pur la fnctin prf a une lngueur fixe, les dnnées furnies cmme clé snt trnquées u burrées avec des zérs en tant que de besin sauf si un traitement exceptinnel est précnisé par la frmule. Le matériel de clés sera tujurs déduit cmme résultat de l algrithme prf négcié.cmme la quantité de matériel de clés nécessaire peut être supérieure à la taille du résultat de l algrithme prf, n utilisera la prf itérativement. On utilisera la terminlgie prf+ pur décrire la fnctin qui dnne un flux pseud-aléatire sur la base des entrées d une prf cmme suit : (ù indique la cncaténatin) prf+ (K,S) = T1 T2 T3 T4... ù : T1 = prf (K, S 0x01) T2 = prf (K, T1 S 0x02) T3 = prf (K, T2 S 0x03) T4 = prf (K, T3 S 0x04)

17 RFC 4306 page Kaufman & autres qui se pursuit cmme nécessaire pur calculer tutes les clés requises. Les clés snt tirées de la chaîne de résultat sans cnsidératin des frntières (par exemple, si les clés requises snt des clés de 256 bits de la nrme de chiffrement évlué (AES) et une clé de 160 bits HMAC, et que la fnctin prf génère 160 bits, la clé AES viendra de T1 et du début de T2, tandis que la clé HMAC viendra du reste de T2 et du cmmencement de T3). La cnstante cncaténée à la fin de chaque chaîne qui alimente la prf est un seul ctet. prf+ dans le présent dcument n est pas définie au-delà de 255 fis la taille du résultat de la prf Génératin du matériel de clés pur la IKE_SA Les clés partagées snt calculées cmme suit : une quantité appelée SKEYSEED est calculée à partir des nms ccasinnels échangés durant l échange IKE_SA_INIT et le secret Diffie-Hellman partagé établi durant cet échange. SKEYSEED est utilisé pur calculer sept autres secrets : SK_d utilisé pur déduire de nuvelles clés pur les CHILD_SA établies avec cette IKE_SA ; SK_ai et SK_ar utilisés cmme clés pur l algrithme de prtectin d intégrité pur authentifier les messages cmpsants les échanges ultérieurs ; SK_ei et SK_er utilisés pur le chiffrement (et bien sûr, le déchiffrement) de tus les échanges ultérieurs; et SK_pi et SK_pr, qui snt utilisés lrs de la génératin de la charge utile AUTH. SKEYSEED et ses dérivés snt calculés cmme suit : SKEYSEED = prf(ni Nr, g^ir) {SK_d SK_ai SK_ar SK_ei SK_er SK_pi SK_pr } = prf+ (SKEYSEED, Ni Nr SPIi SPIr ) (qui indique que les quantités SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, et SK_pr snt prises dans l rdre des bits générés de la prf+). g^ir est le secret partagé tiré de l échange Diffie-Hellman éphémère. g^ir est représenté cmme une chaîne d ctets en rdre grs butien burrés avec des zérs si nécessaire pur arriver à la lngueur du mdule. Ni et Nr snt les nms ccasinnels, dépuillés de tut en-tête. Si la prf négciée prend une clé de lngueur fixée et si les lngueurs de Ni et Nr n ajutent rien à cette lngueur, la mitié des bits dit venir de Ni et l autre mitié de Nr, en prenant les premiers bits de chaque. Les deux directins de flux de trafic utilisent des clés différentes. Les clés utilisées pur prtéger les messages prvenant de l initiateur d rigine snt SK_ai et SK_ei. Les clés utilisées pur prtéger les messages dans l autre directin snt SK_ar et SK_er. Chaque algrithme prend un nmbre fixé de bits de matériel de clés, qui est spécifié au titre de l algrithme. Pur les algrithmes d intégrité fndés sur un hachage de clés, la taille de clé est tujurs égale à la lngueur du résultat de la fnctin de hachage sus-jacente Authentificatin de la IKE_SA Lrsqu n n utilise pas l authentificatin extensible (vir au paragraphe 2.16) les hmlgues snt authentifiés en ayant un blc de dnnées pur chaque signe (u MAC utilisant un secret partagé cmme clé). Pur le répndant, les ctets à signer cmmencent par le premier ctet du premier SPI dans l en-tête du secnd message et se terminent par le dernier ctet de la dernière charge utile dans le secnd message. Ajuté à cela (pur les besins du calcul de signature) il y a le nm ccasinnel Ni de l initiateur (juste la valeur, pas la charge utile qui la cntient), et la valeur prf(sk_pr,idr') ù IDr' est la charge utile d'identifiant du répndant, en-tête fixe exclu. Nter que ni le nm ccasinnel Ni ni la valeur prf(sk_pr,idr') ne snt transmises. De même, l initiateur signe le premier message, en cmmençant par le premier ctet du premier SPI dans l en-tête et terminant par le dernier ctet de la dernière charge utile. Ajuté à cela (pur les besins du calcul de la signature) se truvent le nm ccasinnel Nr du répndant, et la valeur prf(sk_pi,idi'). Dans le calcul ci-dessus, IDi' et IDr' snt les charge utiles d identifiant entières, en-tête fixe exclu. Il est critique pur la sécurité de l échange que chaque côté signe le nm ccasinnel de l autre côté. Nter que tutes les charges utiles snt incluses sus la signature, y cmpris tus types de charge utile nn définis dans le présent dcument. Si le premier message de l échange est envyé deux fis (la deuxième fis avec un témin du répndant et/u un grupe Diffie-Hellman différent) c est la secnde versin du message qui est signée. Facultativement, les messages 3 et 4 PEUVENT inclure un certificat, u une chaîne de certificats dnnant la preuve que la clé utilisée pur calculer la signature numérique appartient au nm dans la charge utile d identifiant. La signature u MAC sera calculée en utilisant les algrithmes impliqués par le type de clé utilisée par le signataire, et spécifié par le champ Auth Methd (méthde d authentificatin) dans la charge utile Authentificatin. Il n est pas exigé que l initiateur et le répndant signent avec les mêmes algrithmes cryptgraphiques. Le chix des algrithmes cryptgraphiques dépend du type de clés

18 RFC 4306 page Kaufman & autres qu a chacun. En particulier, l initiateur peut utiliser une clé partagée alrs que le répndant a une clé et un certificat de signature publique. Ce sera suvent le cas (mais pas bligatirement) qu un secret partagé sit utilisé pur l authentificatin et que la même clé sit utilisée dans les deux directins. Nter que c est une pratique curante mais typiquement à risque d avir une clé partagée dérivée seulement d un mt de passe chisi par l usager sans incrprer aucune autre surce d aléa. C est typiquement à risque parce que les mts de passe chisis par les usagers n nt vraisemblablement pas l imprévisibilité suffisante pur résister aux attaques de dictinnaire et ces attaques ne snt pas empêchées par la méthde d authentificatin. (Les applicatins qui utilisent l authentificatin fndée sur le mt de passe pur l amrçage et IKE_SA devraient utiliser la méthde d authentificatin du paragraphe 2.16, qui est cnçue pur empêcher les attaques de dictinnaire hrs ligne.) La clé pré-partagée DEVRAIT cntenir autant d imprévisibilité que la plus frte clé négciée. Dans le cas d une clé pré-partagée, la valeur AUTH est calculée par : AUTH = prf(prf(shared Secret,"Key Pad fr IKEv2"), <msg ctets>) ù la chaîne "Key Pad fr IKEv2" est de 17 caractères ASCII sans terminaisn nulle. Le secret partagé peut être de lngueur variable. La chaîne de burrage est ajutée de telle srte que si le secret partagé est déduit d un mt de passe, la mise en œuvre IKE n ait pas besin de mémriser le mt de passe en clair, mais puisse plutôt mémriser la valeur prf(shared Secret,"Key Pad fr IKEv2"), qui ne purrait pas être utilisée cmme un équivalent de mt de passe pur des prtcles autres que IKEv2. Cmme nté ci-dessus, déduire le secret partagé d un mt de passe n est pas sûr. Cette cnstructin est utilisée parce qu n se dute bien que les gens le fernt quand même. L interface de gestin par laquelle est furni le secret partagé DOIT accepter les chaînes ASCII d au mins 64 ctets et NE DOIT PAS ajuter de terminaisn nulle avant de les utiliser cmme secrets partagés. Elle DOIT aussi accepter un cdage HEX du secret partagé. L interface de gestin PEUT accepter d autres cdages si l algrithme de traductin du cdage en chaîne binaire est spécifié. Si la prf négciée prend une clé de taille fixe, le secret partagé DOIT être de cette taille fixe Méthdes de prtcle d authentificatin extensible En plus de l authentificatin utilisant les signatures de clés publiques et les secrets partagés, IKE prend en charge l authentificatin utilisant les méthdes définies dans la RFC 3748 [RFC3748]. Nrmalement, ces méthdes nt asymétriques (cnçues par l authentificatin d un usager auprès d un serveur), et elles peuvent n être pas mutuelles. Pur cette raisn, ces prtcles snt nrmalement utilisés pur authentifier l initiateur auprès du répndant et DOIVENT être utilisées en cnjnctin avec une authentificatin fndée sur la signature de clé publique du répndant auprès de l initiateur. Ces méthdes snt suvent assciées aux mécanismes appelés "authentificatin traditinnelle". Alrs que le présent mémire se réfère à [RFC3748] avec l idée d ajuter de nuvelles méthdes à l avenir sans mettre à jur la présente spécificatin, certaines variantes plus simples snt expsées ici et au paragraphe La [RFC3748] définit un prtcle d authentificatin qui exige un nmbre variable de messages. L authentificatin extensible est mise en œuvre dans IKE sus frme d échanges IKE_AUTH supplémentaires qui DOIVENT être menés à bien afin d initialiser la IKE_SA. Un initiateur indique le désir d utiliser l authentificatin extensible en laissant la charge utile AUTH en dehrs du message 3. En incluant une charge utile IDi mais pas la charge utile AUTH, l initiateur a déclaré une identité mais ne l a pas pruvée. Si le répndant veut utiliser une méthde d authentificatin extensible, il va placer une charge utile de prtcle d authentificatin extensible (EAP, Extensible Authenticatin Prtcl) dans le message 4 et différer l envi de SAr2, TSi, et TSr jusqu à l achèvement de l authentificatin de l initiateur dans un échange IKE_AUTH ultérieur. Dans le cas d une authentificatin extensible minimale, l établissement initial de SA va apparaître cmme suit : Initiateur HDR, SAi1, KEi, Ni HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi, TSr} HDR, SK {EAP} HDR, SK {AUTH} Répndant HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDr, [CERT,] AUTH, EAP } HDR, SK {EAP (succès)} HDR, SK {AUTH, SAr2, TSi, TSr } Pur les méthdes EAP qui créent une clé partagée cmme effet secndaire de l authentificatin, cette clé partagée DOIT être utilisée à la fis par l initiateur et le répndant pur générer des charges utiles AUTH dans les messages 7 et 8 en utilisant la syntaxe des secrets partagés du paragraphe La clé partagée prvenant d EAP est le champ de la

19 RFC 4306 page Kaufman & autres spécificatin EAP nmmé MSK. La clé partagée générée durant un échange IKE NE DOIT PAS être utilisée pu un autre bjet. Les méthdes EAP qui n établissent pas une clé partagée NE DEVRAIENT PAS être utilisées, car elles snt sujettes à un certain nmbre d attaques par interpsitin [EAPMITM] si ces méthdes EAP snt utilisées dans d autres prtcles qui ne se servent pas d un tunnel authentifié par le serveur. Prière de se reprter à la sectin Cnsidératins sur la sécurité pur les détails. Si les méthdes EAP qui ne génèrent pas une clé partagée snt utilisées, les charges utiles AUTH dans les messages 7 et 8 DOIVENT être générées en utilisant respectivement SK_pi et SK_pr. L initiateur d une IKE_SA utilisant EAP DEVRAIT être capable d étendre l échange de prtcle initial à au mins dix échanges IKE_AUTH pur le cas ù le répndant envie des messages de ntificatin et/u réessaye l invite d authentificatin. Une fis que l échange de prtcle défini par la méthde d authentificatin EAP chisie s est achevé avec succès, le répndant DOIT envyer une charge utile EAP cntenant le message Success. De même, si la méthde d authentificatin a échué, le répndant DOIT envyer une charge utile EAP cntenant le message Failure. Le répndant PEUT terminer à tut mment l échange IKE en envyant une charge utile EAP cntenant le message Failure. Après un tel échange étendu, les charges utiles EAP AUTH DOIVENT être incluses dans les deux messages qui suivent celui qui cntient les message EAP Success Génératin du matériel de clés pur les CHILD_SA Une seule CHILD_SA est créée par l échange IKE_AUTH, et des CHILD_SA supplémentaires peuvent facultativement être créées dans les échanges CREATE_CHILD_SA. Le matériel de clés pur elles est généré cmme suit : KEYMAT = prf+(sk_d, Ni Nr) Où Ni et Nr snt les nms ccasinnels prvenant de l échange IKE_SA_INIT si cette demande est la première CHILD_SA créée, u les Ni et Nr frais prvenant de l échange CREATE_CHILD_SA si c est une créatin ultérieure. Pur les échanges CREATE_CHILD_SA qui incluent un échange Diffie-Hellman facultatif, le matériel de clés est défini par : KEYMAT = prf+(sk_d, g^ir (new) Ni Nr ) ù g^ir (new) est le secret partagé prvenant de l échange Diffie-Hellman éphémère de cet échange CREATE_CHILD_SA (représenté par une chaîne d ctets en rdre grs butien burré avec des zérs dans les bits de plus frt pids si nécessaire pur arriver à la lngueur du mdule). Une seule négciatin CHILD_SA peut résulter en plusieurs assciatins de sécurité. Les SA ESP et AH existent par paires (une dans chaque directin), et quatre SA peuvent être créées dans une seule négciatin CHILD_SA si une cmbinaisn de ESP et AH est négciée. Le matériel de clés DOIT être pris à partir du KEYMAT étendu dans l rdre suivant : - Tutes les clés pur les SA qui prtent des dnnées de l initiateur au répndant snt prises avant les SA qui vnt dans la directin inverse. - Si plusieurs prtcles IPsec snt négciés, le matériel de clés est pris dans l rdre dans lequel les en-têtes de prtcle vnt apparaître dans le paquet encapsulé. - Si un seul prtcle a des clés à la fis de chiffrement et d authentificatin, la clé de chiffrement est prise des premiers ctets de KEYMAT et la clé d authentificatin est prise des ctets suivants. Chaque algrithme cryptgraphique prend un nmbre fixe de bits de matériel de clé spécifié par l algrithme Renuvellement des clés des IKE_SA en utilisant l échange CREATE_CHILD_SA L échange CREATE_CHILD_SA peut être utilisé pur renuveler les clés d une IKE_SA existante (vir paragraphe 2.8). Les nuveaux SPI d initiateur et de répndant snt furnis dans les champs de SPI. Les charges utiles de TS snt mises lrs du renuvellement de clés d une IKE_SA. Le SKEYSEED pur la nuvelle IKE_SA est calculé en utilisant le SK_d prvenant de la IKE_SA existante cmme suit :

20 RFC 4306 page Kaufman & autres SKEYSEED = prf(sk_d (ld), [g^ir (new)] Ni Nr) ù g^ir (new) est le secret partagé prvenant de l échange Diffie-Hellman éphémère de cet échange CREATE_CHILD_SA (représenté cmme une chaîne d ctets en rdre grs butien burrée avec des zérs si nécessaire pur arriver à la lngueur du mdule) et Ni et Nr snt les deux nms ccasinnels débarrassés de tut en-tête. La nuvelle IKE_SA DOIT remettre sn cmpteur de messages à 0. SK_d, SK_ai, SK_ar, SK_ei, et SK_er snt calculés à partir du SKEYSEED cmme spécifié au paragraphe Demande d une adresse interne sur un réseau distant Cmme il arrive le plus curamment dans le scénari de pint d extrémité à passerelle de sécurité, un pint d extrémité peut d avir besin d une adresse IP dans le réseau prtégée par la passerelle de sécurité et que cette adresse sit alluée de façn dynamique. Une telle demande d adresse tempraire peut être incluse dans tute demande de créatin d une CHILD_SA (y cmpris la demande implicite dans le message 3) en incluant une charge utile CP. Cette fnctin furnit une allcatin d adresse à un client IPsec d accès distant (IRAC, IPsec Remte Access Client) qui essaye de tunneler dans un réseau prtégé par un serveur IPsec d accès distant (IRAS, IPsec Remte Access Server). Cmme l échange IKE_AUTH crée une IKE_SA et une CHILD_SA, l IRAC DOIT demander l adresse cntrôlées par l IRAS (et facultativement d autres infrmatins cncernant le réseau prtégé) dans l échange IKE_AUTH. L IRAS peut prcurer une adresse pur l IRAC à partir d un certain nmbre de surces telles qu un serveur DHCP/BOOTP u de sn prpre réservir d adresses. Initiateur Répndant HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr} HDR, SK {IDr, [CERT,] AUTH, CP(CFG_REPLY), SAr2, TSi, TSr} Dans tus les cas, la charge utile CP DOIT être insérée avant la charge utile SA. Dans des variantes du prtcle ù il y a plusieurs échanges IKE_AUTH, la charge utile CP DOIT être insérée dans les messages cntenant les charges utiles SA. CP(CFG_REQUEST) DOIT cntenir au mins un attribut INTERNAL_ADDRESS (IPv4 u IPv6) mais PEUT cntenir tut nmbre d attributs supplémentaires que l initiateur veut returner dans la répnse. Par exemple, un message d initiateur à répndant : CP(CFG_REQUEST)= INTERNAL_ADDRESS( ) INTERNAL_NETMASK( ) INTERNAL_DNS( ) TSi = (0, , ) TSr = (0, , ) Nte : Les sélecteurs de trafic cntiennent (prtcle, gamme d accès, gamme d adresse). Message du répndant à l initiateur : CP(CFG_REPLY)= INTERNAL_ADDRESS( ) INTERNAL_NETMASK( ) INTERNAL_SUBNET( / ) TSi = (0, , ) TSr = (0, , ) Tutes les valeurs returnées vnt dépendre de la mise en œuvre. Cmme n peut le vir dans l exemple ci-dessus, l IRAS PEUT aussi envyer d autres attributs qui n étaient pas inclus dans CP(CFG_REQUEST) et PEUT ignrer les attributs nn bligatires qu il ne prend pas en charge. Le répndant NE DOIT PAS envyer de CFG_REPLY sans avir d abrd reçu une CP(CFG_REQUEST) de l initiateur, parce qu n ne veut pas que l IRAS effectue de buclage de cnfiguratin inutile si l IRAC ne peut pas traiter la REPLY. Dans le cas ù la cnfiguratin de l IRAS exige que CP sit utilisé pur une identité IDi dnnée, mais ù l'irac a échué à envyer un CP(CFG_REQUEST), l IRAS DOIT faire échuer la demande, et terminer l échange IKE avec une erreur FAILED_CP_REQUIRED.

21 RFC 4306 page Kaufman & autres 2.20 Demande de la versin de l hmlgue Un hmlgue IKE suhaitant s enquérir de la versin du lgiciel IKE de l autre hmlgue PEUT utiliser la méthde suivante. C est un exemple de demande de cnfiguratin au sein d un échange INFORMATIONAL, après la créatin de la IKE_SA et de la première CHILD_SA. Une mise en œuvre IKE PEUT refuser de divulguer ses infrmatins de versin avant l authentificatin u même après l authentificatin pur empêcher la cntagin au cas u certaines mises en œuvre seraient réputées avir des failles dans leur sécurité. Dans ce cas, elle DOIT returner une chaîne vide u pas de charge utile CP si CP n est pas pris en charge. Initiateur HDR, SK{CP(CFG_REQUEST)} Répndant HDR, SK{CP(CFG_REPLY)} CP(CFG_REQUEST)=APPLICATION_VERSION("") CP(CFG_REPLY) APPLICATION_VERSION("fbar v1.3beta, (c) F Bar Inc.") 2.21 Traitement des erreurs De nmbreuses srtes d erreurs peuvent survenir pendant le traitement IKE. Si une demande mal frmatée est reçue u si elle est inacceptable pur des raisns de plitique (par exemple, pas d algrithme cryptgraphique qui crrespnde) la répnse DOIT cntenir une charge utile Ntify qui indique l erreur. Si une erreur survient en dehrs du cntexte d une demande IKE (par exemple, le nœud btient des messages ESP sur un SPI qui n existe pas), le nœud DEVRAIT initier un échange INFORMATIONAL avec une charge utile Ntify décrivant le prblème. Les erreurs qui surviennent avant l établissement d une IKE_SA prtégée cryptgraphiquement divent être traitées avec beaucup de prudence. Il y a un cmprmis à faire entre vulir aider à diagnstiquer un prblème et y répndre et vulir éviter d être la dupe d une attaque de déni de service fndée sur des messages falsifiés. Si un nœud reçit un message sur l'accès UDP 500 u 4500 en dehrs du cntexte d une IKE_SA cnnue de lui (et nn une demande d en cmmencer une) cela peut être le résultat d une défaillance récente du nœud. Si le message est marqué cmme répnse, le nœud PEUT auditer l événement suspect mais NE DOIT PAS répndre. Si le message est marqué cmme demande, le nœud PEUT auditer l événement suspect et PEUT envyer une répnse. Si une répnse est envyée, la répnse DOIT être envyée à l adresse et accès IP d ù elle est venue avec les mêmes SPI IKE et l identifiant de message cpié. La répnse NE DOIT PAS être prtégée cryptgraphiquement et DOIT cntenir une charge utile Ntify indiquant INVALID_IKE_SPI. Un nœud qui reçit une telle charge utile Ntify nn prtégée NE DOIT PAS répndre et NE DOIT changer l état d aucune des SA existantes. Le message peut être une falsificatin u peut être une répnse que le véritable crrespndant a été cnduit par fraude à envyer. Un nœud DEVRAIT traiter un tel message (et aussi un message réseau cmme une destinatin inaccessible ICMP) cmme l indicatin qu il purrait y avir des prblèmes avec des SA à cette adresse IP et DEVRAIT lancer une vérificatin de vie pur tute IKE_SA de cette srte. Une mise en œuvre DEVRAIT limiter la fréquence de telles vérificatins pur éviter de se faire manipuler dans une participatin à une attaque de déni de service. Un nœud qui reçit un message suspect d une adresse IP avec laquelle il a une IKE_SA PEUT envyer une charge utile IKE Ntify dans un échange IKE INFORMATIONAL sur cette SA. Le receveur NE DOIT changer l état d aucune des SA à la suite de cela mais DEVRAIT faire un audit de l événement pur aider au diagnstic des dysfnctinnements. Un nœud DOIT limiter le débit auquel il va envyer des messages en répnse à des messages nn prtégés IPCmp L utilisatin de la cmpressin IP [RFC3173] peut être négciée au titre de l établissement d une CHILD_SA. Alrs que la cmpressin IP implique un en-tête supplémentaire dans chaque paquet et un indice de paramètre de cmpressin (CPI), l assciatin de cmpressin virtuelle n a pas de vie en dehrs de la SA ESP u AH qui la cntient. Les assciatins de cmpressin disparaissent lrsque la SA ESP u AH crrespndante s en va. Elle n est pas mentinnée explicitement dans une charge utile DELETE. La négciatin de la cmpressin IP est séparée de la négciatin des paramètres cryptgraphiques assciés à une CHILD_SA. Un nœud qui demande une CHILD_SA PEUT faire cnnaître sn sutien à un u plusieurs algrithmes de cmpressin à travers une u plusieurs charges utiles Ntify de type IPCOMP_SUPPORTED. La répnse PEUT indiquer l acceptatin d un seul algrithme de cmpressin avec une charge utile Ntify du type IPCOMP_SUPPORTED. Ces

22 RFC 4306 page Kaufman & autres charges utiles NE DOIVENT PAS survenir dans des messages qui ne cntiennent pas de charge utile SA. Bien qu il y ait eu des discussins sur la questin de savir si plusieurs algrithmes de cmpressin divent être acceptés et si n peut avir des algrithmes de cmpressin différents dispnibles pur les deux directins d une CHILD_SA, les mises en œuvre de la présente spécificatin NE DOIVENT PAS accepter un algrithme IPCmp qui n a pas été prpsé, NE DOIVENT PAS en accepter plus d un, et NE DOIVENT PAS cmpresser en utilisant un algrithme autre que celui prpsé et accepté dans l établissement de la CHILD_SA. Un effet cllatéral de la séparatin de la négciatin de IPCmp et des paramètres cryptgraphiques est qu il n est pas pssible de prpser plusieurs suites cryptgraphiques et de prpser la cmpressin IP avec certaines mais pas avec les autres Traversée de NAT Les passerelles de traductin d adresse réseau (NAT, Netwrk Address Translatin) snt un sujet cntrversé. Ce paragraphe décrit brièvement purqui elles le snt et cmment elles vnt vraisemblablement agir sur le trafic IKE. Beaucup crient que les NAT snt diabliques et que nus devrins cncevir ns prtcles de façn à les faire mieux fnctinner. IKEv2 spécifie effectivement quelques règles de traitement bjectives afin que les NAT aient plus de chances de fnctinner. Les NAT existent principalement à cause de la pénurie d adresses IPv4, bien qu il y ait aussi d autres raisns. Les nœuds IP qui snt "derrière" un NAT nt des adresses IP qui ne snt pas uniques au mnde, mais snt plutôt alluées à partir d un espace qui est unique au sien du réseau derrière le NAT mais sernt vraisemblablement réutilisées par des nœuds derrière d autres NAT. Généralement, les nœuds derrière des NAT peuvent cmmuniquer avec d autres nœuds derrière le même NAT et avec des nœuds avec des adresses uniques au mnde, mais pas avec des nœuds derrière d autres NAT. Il y a des exceptins à cette règle. Lrsque ces nœuds fnt des cnnexins avec des nœuds sur l Internet réel, la passerelle NAT "traduit" l adresse IP de surce en une adresse qui sera réacheminée sur la passerelle. Les messages pur la passerelle venant de l Internet nt leurs adresses de destinatin "traduites" en une adresse interne qui va acheminer le paquet au bn nœud terminal. Les NAT snt cnçus pur être "transparents" pur les nœuds terminaux. Le lgiciel sur le nœud qui est derrière le NAT ni le nœud sur l Internet n exigent de mdificatin pur cmmuniquer à travers le NAT. Réaliser cette transparence est plus difficile avec certains prtcles qu avec d autres. Les prtcles qui incluent les adresses IP des pints d extrémité au sein des charges utiles du paquet vnt échuer sauf si la passerelle NAT cmprend le prtcle et mdifie les références internes ainsi que celles dans les en-têtes. Un tel savir est par nature nn fiable, c est une vilatin de la cuche réseau, et il en résulte suvent des prblèmes subtils. Ouvrir une cnnexin IPsec à travers un NAT intrduit des prblèmes particuliers. Si la cnnexin fnctinne en mde transprt, changer les adresses IP sur les paquets va causer l échec des smmes de cntrôle et le NAT ne peut pas crriger les smmes de cntrôle parce qu elles snt prtégées cryptgraphiquement. Même en mde tunnel, il y a des prblèmes d acheminement parce que la traductin transparente des adresses des paquets AH et ESP exige une lgique particulière dans le NAT et cette lgique est heuristique et nn fiable par nature. Pur cette raisn, IKEv2 peut négcier l encapsulatin UDP des paquets IKE et ESP. Ce cdage est légèrement mins efficace mais il est plus facile à traiter pur les NAT. De plus, le pare-feu peut être cnfiguré pur passer le trafic IPsec sur UDP mais pas ESP/AH u vice versa. Il est de pratique curante que les NAT traduisent les numérs d'accès TCP et UDP aussi bien que les adresses et utilisent les numérs d'accès des paquets entrants pur décider quel nœud interne va btenir tel paquet. Pur cette raisn, même si les paquets IKE DOIVENT être envyés de et vers l'accès UDP 500, ils DOIVENT être acceptés en prvenance de tus les accès et les répnses DOIVENT être envyées à l'accès d ù ils prviennent. C est parce que les accès peuvent être mdifiés lrsque les paquets passent à travers les NAT. De même, les adresses IP des pints d extrémité IKE ne snt généralement pas incluses dans les charges utiles IKE parce que les charges utiles snt prtégées cryptgraphiquement et purraient n être pas mdifiées de façn transparente par les NAT. L'accès 4500 est réservé à ESP et IKE encapsulé en UDP. Lrsqu n travaille à travers un NAT, il est généralement préférable de passer les paquets IKE sur l'accès 4500 parce que certains NAT plus anciens traitent habilement le trafic IKE sur l'accès 500 pur essayer d établir des cnnexins IPsec de façn transparente entre des pin0ts d extrémité qui ne traitent pas eux-mêmes la traversée de NAT. De tels NAT peuvent interférer avec la traversée de NAT directe envisagée dans le présent dcument, aussi un pint d extrémité IPsec qui décuvre un NAT entre lui et sn crrespndant DOIT envyer tut le trafic ultérieur de et vers l'accès 4500, que les NAT ne devraient pas traiter de façn particulière (cmme ils le fnt avec l'accès 500).

23 RFC 4306 page Kaufman & autres Les exigences spécifiques de la prise en charge de la traversée de NAT [RFC3715] figurent ci-dessus. La prise en charge de la traversée de NAT est facultative. Dans ce seul paragraphe, les exigences énumérées DOIVENT s appliquer aux seules mises en œuvre qui prennent en charge la traversée de NAT. IKE DOIT écuter sur l'accès 4500 ainsi que sur l'accès 500. IKE DOIT répndre à l adresse et accès IP d ù snt arrivés les paquets. L initiateur et le répndant IKE DOIVENT tus deux inclure dans leurs paquets IKE_SA_INIT des charges utiles Ntify du type NAT_DETECTION_SOURCE_IP et NAT_DETECTION_DESTINATION_IP. Ces charges utiles peuvent être utilisées pur détecter si il y a un NAT entre les hôtes, et quelle extrémité est derrière le NAT. La lcalisatin des charges utiles dans les paquets IKE_SA_INIT est juste après les charge utiles Ni et Nr (avant la charge utile facultative CERTREQ). Si aucune des charges utiles NAT_DETECTION_SOURCE_IP reçues ne crrespnd au hachage de la surce et accès IP truvés dans l en-tête IP du paquet qui cntient la charge utile, cela signifie que l autre extrémité est derrière un NAT (c est-à-dire que quelqu un le lng de la rute a changé l adresse de surce du paquet d rigine pur crrespndre à l adresse du NAT). Dans ce cas, cette extrémité devrait permettre une mise à jur dynamique de l adresse IP de l autre extrémité, cmme il sera décrit plus lin. Si la charge utile NAT_DETECTION_DESTINATION_IP reçue ne crrespnd pas au hachage de la destinatin et accès IP truvés dans l en-tête IP du paquet qui cntient la charge utile, cela signifie que cette extrémité est derrière un NAT. Dans ce cas, cette extrémité DEVRAIT cmmencer à envyer des paquets Garder-en-vie cmme expliqué dans la [RFC3948]. L initiateur IKE DOIT vérifier ces charges utiles si elles snt présentes et si elles ne crrespndent pas aux adresses dans le paquet externe, il DOIT tunneler tus les futurs paquets IKE et ESP assciés à cette IKE_SA sur l'accès UDP Pur tunneler les paquets IKE sur l'accès UDP 4500, l en-tête IKE a quatre ctets de zérs ajutés en tête et le résultat suit immédiatement l en-tête UDP. Pur tunneler les paquets ESP sur l'accès UDP 4500, l en-tête ESP suit immédiatement l en-tête UDP. Cmme les quatre premiers ctets de l en-tête ESP cntiennent le SPI, et que le SPI ne peut pas être à zér et valide, il est tujurs pssible de distinguer les messages ESP et IKE. Les adresses IP de surce et de destinatin riginales nécessaires pur le dispsitif de smme de cntrôle de paquet TCP et UDP en mde transprt (vir la [RFC3948]) snt btenues des sélecteurs de trafic assciés à l échange. Dans le cas de traversée de NAT, les sélecteurs de trafic DOIVENT cntenir exactement une adresse IP, qui est alrs utilisée cmme l adresse IP d rigine. Il y a des cas ù un NAT décide de retirer les transpsitins qui snt tujurs actives (par exemple, l intervalle de garder-en-vie est trp lng, u le NAT est réinitialisé). Pur récupérer les adresses dans ces cas là, les hôtes qui ne snt pas derrière un NAT DEVRAIENT envyer tus les paquets (y cmpris les paquets de retransmissin) à l adresse et l'accès IP prvenant du dernier paquet valide authentifié de l autre extrémité (c est-à-dire, mettre à jur l adresse de façn dynamique). Un hôte derrière un NAT NE DEVRAIT PAS faire cela parce qu il uvre une pssibilité d attaque de DS. Tut paquet IKE authentifié u tut paquet ESP encapsulé en UDP authentifié peut être utilisé pur détecter que l adresse u l'accès IP a changé. Nter que des actins similaires mais prbablement pas identiques sernt vraisemblablement nécessaires pur faire fnctinner IKE avec IP mbile, mais un tel traitement n est pas visé par le présent dcument Ntificatin explicite d encmbrement (ECN) Lrsque des tunnels IPsec se cmprtent cmme spécifié à l rigine dans la [RFC2401], l usage d ECN n est pas apprprié pur les en-têtes IP externes parce que le traitement de désencapsulatin de tunnel élimine les indicatins d encmbrement ECN au détriment du réseau. La prise en charge par ECN des tunnels IPsec pur IPsec fndé sur IKEv1 exige plusieurs mdes de fnctinnement et négciatins (vir la [RFC3168]). IKEv2 simplifie cette situatin en exigeant que ECN sit utilisable dans les en-têtes IP externes de tutes les SA IPsec en mde tunnel créées par IKEv2. En particulier, les encapsuleurs et désencapsuleurs de tunnel pur tutes les SA en mde tunnel créées par IKEv2 DOIVENT prendre en charge l ptin ECN de pleine fnctinnalité pur les tunnels spécifiée dans la [RFC3168] et DOIVENT mettent en œuvre le traitement d encapsulatin et désencapsulatin de tunnel spécifiée dans la [RFC4301] pur empêcher l éliminatin des indicatins d encmbrement ECN.

24 RFC 4306 page Kaufman & autres 3 Frmats d en-tête et de charge utile 3.1 L en-tête IKE Les messages IKE utilisent les accès UDP 500 et/u 4500, avec un message IKE par datagramme UDP. Les infrmatins prvenant du début du paquet à travers l en-tête UDP snt largement ignrées, à l exceptin des adresses IP et accès UDP prvenant des en-têtes qui snt inversés et utilisés pur les paquets de retur. Lrsqu ils snt envyés sur l'accès UDP 500, les messages IKE cmmencent immédiatement après l en-tête UDP. Lrsqu ils snt envyés sur l'accès UDP 4500, les messages IKE nt quatre ctets de zérs ajutés en tête. Ces quatre ctets de zérs ne fnt pas partie du message IKE et ne snt inclus dans aucun des champs de lngueur u de smme de cntrôle définis par IKE. Chaque message IKE cmmence par l en-tête IKE, nté HDR dans le présent mémire. Suivant l en-tête se truvent une u plusieurs charges utiles IKE, chacune identifiée par un champ "Prchaine charge utile" dans la charge utile précédente. Les charges utiles snt traitées dans l rdre dans lequel elles apparaissent dans un message IKE en invquant la rutine de traitement apprpriée cnfrmément au champ "Prchaine charge utile" dans l en-tête IKE et ensuite cnfrmément au champ "Prchaine charge utile" dans la charge utile IKE elle-même jusqu à ce qu un champ "Prchaine charge utile" de zér indique qu aucune charge utile ne suit. Si une charge utile de type "Chiffrée" est truvée, cette charge utile est déchiffrée et sn cntenu est analysé cmme des charges utiles supplémentaires. Une charge utile Chiffrée DOIT être la dernière charge utile dans un paquet et une charge utile Chiffrée NE DOIT PAS cntenir d autre charge utile Chiffrée. Le SPI du receveur dans l en-tête identifie une instance d assciatin de sécurité IKE. Il est dnc pssible à une seule instance de IKE de multiplexer des sessins distinctes avec plusieurs hmlgues. Tus les champs multi ctets représentant des entiers snt dispsés en rdre grs butien (à savir l ctet de plus frt pids d abrd, u dans l rdre des ctets du réseau). Le frmat de l en-tête IKE est dnné à la Figure ! SPI de l'initiateur de IKE_SA!! SPI du répndant à IKE_SA SPI!!Prch ch. utile! MjVer! MnVer!Type d'échange! Fanins!! ID de message!! Lngueur! Figure 4 : Frmat d en-tête IKE SPI de l initiateur (8 ctets) - Valeur chisie par l initiateur pur identifier une assciatin de sécurité IKE unique. Cette valeur NE DOIT PAS être zér. SPI du répndant (8 ctets) - Valeur chisie par le répndant pur identifier une assciatin de sécurité IKE unique. Cette valeur DOIT être zér dans le premier message d un échange initial IKE (y cmpris les répétitins de ce message cmprtant un témin) et NE DOIT PAS être zér dans tut autre message. Prchaine charge utile (1 ctet) Indique le type de charge utile qui suit immédiatement l en-tête. Le frmat et la valeur de chaque charge utile snt définis ci-dessus. Versin majeure (MjVer) (4 bits) Indique la versin majeure du prtcle IKE utilisé. Les mises en œuvre fndées sur cette versin de IKE DOIVENT mettre Versin majeure à 2. Les mises en œuvre fndées sur des versins précédentes de IKE et ISAKMP DOIVENT mettre Versin majeure à 1. Les mises en œuvre fndées sur la présente versin de IKE DOIVENT rejeter u ignrer les messages qui cntiennent un numér de versin supérieur à 2. Versin mineure (MnVer) (4 bits) Indique la versin mineure du prtcle IKE utilisé. Les mises en œuvre fndées sur cette versin de IKE DOIVENT mettre Versin mineure à 0. Elles DOIVENT ignrer le numér de versin mineur des messages reçus. Type d échange (1 ctet) Indique le type d échange utilisé. Ceci cnstitue une cntrainte pur les charges utiles envyées dans chaque message et l rdre des messages dans un échange.

25 RFC 4306 page Kaufman & autres Type d échange Valeur Réservé 0-33 IKE_SA_INIT 34 IKE_AUTH 35 CREATE_CHILD_SA 36 Infrmatin 37 Réservé à l'iana Réservé pur utilisatin privée Fanins (1 ctet) Indique les ptins spécifiques qui snt établies pur le message. La présence d ptins est indiquée par l établissement du bit apprprié dans le champ de fanins. Les bits snt définis avec le bit de plus frt pids d abrd, ainsi le bit 0 serait le bit de mindre pids de l ctet Fanins. Dans la descriptin ci-dessus, un bit mis signifie que sa valeur est '1', alrs que ôté signifie que sa valeur est '0'. -- X(réservé) (bits 0-2) - Ces bits DOIVENT être ôtés lrs de l envi et DOIVENT être ignrés à réceptin. -- I(nitiateur) (bit 3 de Fanins) - Ce bit DOIT être mis dans les messages envyés par l initiateur riginal de la IKE_SA et DOIT être ôté dans les messages envyés par le répndant d rigine. Il est utilisé par le receveur pur déterminer quels snt les huit ctets du SPI qui nt été générés par le receveur. -- V(ersin) (bit 4 de Fanins) - Ce bit indique que l émetteur est capable de traiter un numér de versin majeur du prtcle supérieur à celui indiqué par le champ numér de versin majeur. Les mises en œuvre de IKEv2 DOIVENT ôter ce bit à l envi et DOIVENT l ignrer dans les messages entrants. -- R(épnse) (bit 5 de Fanins) - Ce bit indique que ce message est une répnse à un message cntenant le même identifiant de message. Ce bit DOIT être ôté dans tus les messages de demande et DOIT être mis dans tutes les répnses. Un pint d extrémité IKE NE DOIT PAS générer une répnse à un message marqué cmme étant une répnse. -- X(réservé) (bits 6-7 de Fanins) - Ces bits DOIVENT être ôtés à l envi et DOIVENT être ignrés à réceptin. identifiant de message (4 ctets) Identifiant de message utilisé pur cntrôler la retransmissin des paquets perdus et faire crrespndre demandes et répnses. Il est essentiel à la sécurité du prtcle parce qu il est utilisé pur empêcher les attaques en répétitin de message. Vir les paragraphes 2.1 et 2.2. Lngueur (4 ctets) - Lngueur du message ttal (en-tête + charges utiles) en ctets. 3.2 En-tête générique de charge utile Chaque charge utile IKE définit des paragraphes 3.3 à 3.16 cmmence par un en-tête générique de charge utile, mntré à la Figure 5. Les figures pur chaque charge utile ci-dessus incluent l en-tête générique de charge utile, qui sera mis pur abréger la descriptin de chaque champ !Prch ch. utile!c! Réservé! Lngueur de charge utile! Figure 5 : En-tête générique de charge utile Les champs d en-tête générique de charge utile snt définis cmme suit : Prchaine charge utile (1 ctet) Identifiant du type de charge utile de la prchaine charge utile dans le message. Si la charge utile en curs est la dernière du message, ce champ sera alrs 0. Ce champ dnne une capacité de "chaînage" grâce à laquelle des charges utiles supplémentaires peuvent être ajutées à un message en les accrchant à la fin du message et en réglant le champ "Prchaine charge utile" de la charge utile précédente de façn à indiquer le type de la nuvelle charge utile. Une charge utile Chiffrée, qui dit tujurs être la dernière charge utile d un message, est une exceptin. Elle cntient les structures des dnnées dans le frmat des charges utiles additinnelles. Dans l en-tête d une charge utile Chiffrée, le champ Prchaine charge utile est réglé au type de charge utile de la première charge utile cntenue (au lieu de 0). Valeurs de type de charge utile Prchain type de charge utile Ntatin Valeur Pas de prchaine charge utile 0 Réservé 1-32 Assciatin de sécurité SA 33

26 RFC 4306 page Kaufman & autres Échange de clé KE 34 Identificatin Initiateur IDi 35 Identificatin Répndant IDr 36 Certificat CERT 37 Demande de certificat CERTREQ 38 Authentificatin AUTH 39 Nm ccasinnel Ni, Nr 40 Ntifier N 41 SupprimerDelete D 42 ID de fabricant V 43 Sélecteur de trafic Initiateur TSi 44 Sélecteur de trafic Répndant TSr 45 Chiffré E 46 Cnfiguratin CP 47 Authentificatin extensible EAP 48 Réservé À IANA Usage privé Les valeurs de type de charge utile de 1 à 32 ne devraient pas être utilisées de façn qu il n y ait pas de chevauchement avec les allcatins de cde de IKEv1. Les valeurs de type de charge utile de 49 à 127 snt réservées à l IANA pur des allcatins futures dans IKEv2 (vir la sectin 6). Les valeurs de type de charge utile de 128 à 255 snt pur un usage privé entre des parties mutuellement cnsentantes. C(ritique) (1 bit) - DOIT être mis à zér si l envyeur veut que le receveur saute cette charge utile si il ne cmprend pas le cde de type de charge utile dans le champ Prchaine charge utile de la charge utile précédente. DOIT être mis à un si l envyeur veut que le receveur rejette la ttalité du message si il ne cmprend pas le type de charge utile. DOIT être ignré par le receveur si il cmprend le cde de type de charge utile. DOIT être mis à zér pur les types de charge utile définis dans ce dcument. Nter que le bit critique s applique à la charge utile en curs plutôt qu à la prchaine charge utile dnt le cde de type apparaît dans le premier ctet. Le raisnnement derrière le nn établissement du bit critique pur les charges utiles définies dans le présent dcument est que tutes les mises en œuvre DOIVENT cmprendre tus les types de charges utiles définis dans ce dcument et divent dnc ignrer la valeur du bit Critique. Les charges utiles sautées snt suppsées avir des champs Prchaine charge utile et Lngueur de charge utile valides. Réservé (7 bits) - DOIT être envyé à zér ; DOIT être ignré à réceptin. Lngueur de charge utile (2 ctets) - Lngueur en ctets de la charge utile en curs, y cmpris l en-tête générique de charge utile. 3.3 Charge utile d assciatin de sécurité La charge utile d assciatin de sécurité, ntée SA dans le présent mémire, est utilisée pur négcier les attributs d une assciatin de sécurité. L assemblage des charges utiles d assciatin de sécurité exige une grande sérénité. Une charge utile de SA PEUT cntenir plusieurs prpsitins. S il y en a plus d une, elles DOIVENT être rdnnées par préférence décrissante. Chaque prpsitin peut cntenir plusieurs prtcles IPsec (un prtcle IKE, ESP, u AH). Chaque prtcle PEUT cntenir plusieurs transfrmatins, et chaque transfrmatin PEUT cntenir plusieurs attributs. Quand elle analyse une SA, une mise en œuvre DOIT vérifier que la lngueur de charge utile ttale est chérente avec les lngueurs internes et cmptes de charges utiles. Prpsitins, transfrmatins, et attributs nt chacun leurs prpres cdages de lngueur de variable. Ils snt incrprés de telle srte que la lngueur de charge utile d une SA inclut le cntenu cmbiné des infrmatins de SA, de prpsitin, de transfrmatin, et d attribut. La lngueur d une prpsitin inclut les lngueurs de tutes les transfrmatins et attributs qu elle cntient. La lngueur d une transfrmatin inclut les lngueurs de tus les attributs qu elle cntient. La syntaxe des assciatins de sécurité, prpsitins, transfrmatins, et attributs est fndée sur ISAKMP ; cependant, la sémantique est un peu différente. La raisn de la cmplexité et de la hiérarchie est de permettre qu il sit pssible de cder plusieurs cmbinaisns d algrithmes dans une seule SA. Parfis il y a un chix entre plusieurs algrithmes, alrs que d autres fis il y a une cmbinaisn d algrithmes. Par exemple, un initiateur peut vulir prpser d utiliser (AH avec MD5 et ESP avec 3DES) OU (ESP avec MD5 et 3DES). Une des raisns du changement de la sémantique des charges utiles de SA depuis ISAKMP et IKEv1 est de rendre les cdages plus cmpacts dans les cas curants.

27 RFC 4306 page Kaufman & autres La structure Prpsal cntient en sn sein un numér de prpsitin et un identifiant de prtcle IPsec. Chaque structure DOIT avir le même n de prpsitin que le précédent u lui être supérieur de un (1). La première prpsitin DOIT avir un n de prpsitin de un (1). Si deux structures successives nt le même numér de prpsitin, cela signifie que la prpsitin cnsiste en la première structure ET la secnde. Ainsi la prpsitin de AH ET ESP aurait deux structures de prpsitin, une pur AH et une pur ESP et les deux auraient Prpsal n 1. Une prpsitin de AH OU ESP aurait deux structures de prpsitin, une pur AH avec Prpsal n 1 et une pur ESP avec Prpsal n 2. Chaque structure de prpsitin/prtcle est suivie par une u plusieurs structures de transfrmatin. Le nmbre de transfrmatins différentes est généralement déterminé par le prtcle. Généralement, AH a une seule transfrmatin : un algrithme de vérificatin d intégrité. Généralement, ESP en a deux : un algrithme de chiffrement et un algrithme de vérificatin d intégrité. Généralement, IKE a quatre transfrmatins : un grupe Diffie-Hellman, un algrithme de vérificatin d intégrité, un algrithme de prf, et un algrithme de chiffrement. Si un algrithme qui cmbine chiffrement et prtectin d intégrité est prpsé, il DOIT être prpsé cmme algrithme de chiffrement et un algrithme de prtectin d intégrité NE DOIT PAS être prpsé. Pur chaque prtcle, l ensemble des transfrmatins permises est celui des numérs d identifiant de transfrmatins allués, qui apparaissent dans l en-tête de chaque transfrmatin. Si il y a plusieurs transfrmatins avec le même type Transfrm, ces transfrmatins cnstituent un grupe dans lequel exactement une transfrmatin sera chisie. Si il y a plusieurs de ces grupes, la prpsitin est un ET des chix parmi ces différents grupes. Par exemple, pur prpser ESP avec (3DES u IDEA) et (HMAC_MD5 u HMAC_SHA), la prpsitin ESP cntiendrait deux candidats Transfrm de type 1 (un pur 3DES et un pur IDEA) et deux candidats Transfrm de type 2 (un pur HMAC_MD5 et un pur HMAC_SHA). Cela prpse effectivement quatre cmbinaisns d algrithmes. Si l initiateur vulait prpser seulement un sus-ensemble de ceux-ci, par exemple (3DES et HMAC_MD5) u (IDEA et HMAC_SHA), il n y a aucun myen de cder cela cmme plusieurs transfrmatins au sein d une seule prpsitin. À la place, l initiateur devrait cnstruire deux prpsitins différentes, chacune avec deux transfrmatins. Une transfrmatin dnnée PEUT avir un u plusieurs attributs. Les attributs snt nécessaires quand la transfrmatin peut être utilisée de plus d une façn, cmme quand un algrithme de chiffrement a une taille de clé variable. La transfrmatin spécifierait l algrithme et l attribut spécifierait la taille de clé. La plupart des transfrmatins n nt pas d attribut. Une transfrmatin NE DOIT PAS avir plusieurs attributs du même type. Pur prpser des valeurs de remplacement pur un attribut (par exemple, plusieurs tailles de clé pur l algrithme de chiffrement AES) et une mise en œuvre DOIT inclure plusieurs transfrmatins avec le même type Transfrm, chacun avec un seul attribut. Nter que la sémantique des transfrmatins et des attributs est assez différente de celle de IKEv1. Dans IKEv1, une seule transfrmatin prtait plusieurs algrithmes pur un prtcle dnt un prté dans Transfrm et les autres prtés dans les attributs !Prch ch. utile!c! Réservé! Lngueur de charge utile! ~ <Prpsitins> ~ Figure 6 : Charge utile Assciatin de sécurité Prpsitins (variable) - Une u plusieurs sus-structures de prpsitins. Le type de charge utile pur la charge utile Assciatin de sécurité est trente tris (33) Sus-structure de prpsitin ! 0 (dern) u 2! Réservé! Lngueur de prpsitin!!n prpsitin! ID prtcle! Taille SPI! n Transfrms! ~ SPI (variable) ~

28 RFC 4306 page Kaufman & autres ~ <Transfrms> ~ Figure 7 : Sus-structure de prpsitin 0 (dernière) u 2 (plus) (1 ctet) Spécifie si c est la dernière sus-structure de prpsitin dans la SA. Cette syntaxe est héritée de ISAKMP, mais n est pas nécessaire parce que la dernière prpsitin purrait être identifiée à partir de la lngueur de la SA. La valeur (2) crrespnd à un type de charge utile de prpsitin dans IKEv1, et les quatre premiers ctets de la structure Prpsitin snt cnçus pur ressembler un peu à l en-tête d une charge utile. Réservé (1 ctet) - DOIT être envyé à zér ; DOIT être ignré à réceptin. Lngueur de prpsitin (2 ctets) Lngueur de cette prpsitin, y cmpris tutes les transfrmatins et attributs qui suivent. N de prpsitin (1 ctet) Lrsque une prpsitin est faite, la première prpsitin dans une charge utile de SA DOIT être n 1, et les prpsitins suivantes DOIVENT sit être les mêmes que la prpsitin précédente (indiquant un ET des deux prpsitins) u un de plus que la prpsitin précédente (indiquant un OU des deux prpsitins). Lrsqu une prpsitin est acceptée, tus les numérs de prpsitin dans la charge utile de SA DOIVENT être les mêmes et DOIVENT crrespndre au numér de la prpsitin envyée qui a été accepté. Identifiant de prtcle (1 ctet) Spécifie l identifiant de prtcle IPsec pur la négciatin en curs. Les valeurs définies snt : Prtcle Identifiant de prtcle Réservé 0 IKE 1 AH 2 ESP 3 Réservé à IANA Usage privé Taille de SPI (1 ctet) - Pur une négciatin de IKE_SA initiale, ce champ DOIT être à zér ; le SPI est btenu de l en-tête externe. Durant les négciatins ultérieures, sa taille en ctets est égale à celle du SPI du prtcle crrespndant (8 pur IKE, 4 pur ESP et AH). n de transfrmatin (1 ctet) - Spécifie le nmbre de transfrmatins dans cette prpsitin. SPI (variable) SPI de l entité qui envie. Même si la taille de SPI n est pas un multiple de 4 ctets, aucun burrage n est appliqué à la charge utile. Lrsque le champ Taille de SPI est zér, ce champ n est pas présent dans la charge utile Assciatin de sécurité. Transfrmatins (variable) - Une u plusieurs sus-structures de transfrmatins Sus-structure de transfrmatin ! 0 (dern.) u 3! Réservé! Lngueur de transfrmatin!!type de transf! Réservé! Identifiant de transfrmatin! ~ Attributs de transfrmatin ~ Figure 8 : Sus-structure de transfrmatin 0 (dernière) u 3 (plus) (1 ctet) Spécifie si c est la dernière sus-structure de transfrmatin dans la prpsitin. Cette syntaxe est héritée de ISAKMP, mais est inutile parce que la dernière transfrmatin purrait être identifiée à partir de la lngueur de la prpsitin. La valeur (3) crrespnd à un type de charge utile de Transfrm dans IKEv1, et les quatre premiers ctets de la structure Transfrm snt cnçus pur ressembler un peu à l en-tête d une charge utile. Réservé - DOIT être mis à zér ; DOIT être ignré en réceptin.

29 RFC 4306 page Kaufman & autres Lngueur de transfrmatin Lngueur (en ctets) de la sus-structure Transfrmatin y cmpris l en-tête et les attributs. Type de transfrmatin (1 ctet) - Type de transfrmatin spécifié dans cette transfrmatin. Différents prtcles prennent en charge différents types de transfrmatin. Pur certains prtcles, certaines des transfrmatins peuvent être facultatives. Si une transfrmatin est facultative et si l initiateur suhaite prpser que la transfrmatin sit mise, aucune transfrmatin du type dnné n est incluse dans la prpsitin. Si l initiateur suhaite rendre la transfrmatin facultative pur le répndant, il inclut une sus-structure de transfrmatin avec un identifiant de transfrmatin = 0 cmme une des ptins. Identifiant de transfrmatin (2 ctets) - Instance spécifique du type de transfrmatin prpsé. Valeurs de type de transfrmatin Type de transfrmatin Utilisé dans Réservé 0 Algrithme de chiffrement (ENCR) 1 (IKE et ESP) Fnctin pseud-aléatire (PRF) 2 (IKE) Algrithme d intégrité (INTEG) 3 IKE, AH, facultatif en ESP) Grupe Diffie-Hellman (D-H) 4 IKE, facultatif en AH & ESP) Numér de séquence étendu (ESN) 5 (AH et ESP) Réservé à IANA Usage privé Pur la transfrmatin de type 1 (Algrithme de chiffrement), les identifiants de transfrmatin définis snt : Nm Numér Défini dans Réservé 0 ENCR_DES_IV64 1 (RFC 1827) ENCR_DES 2 (RFC 2405), [DES] ENCR_3DES 3 (RFC 2451) ENCR_RC5 4 (RFC 2451) ENCR_IDEA 5 (RFC 2451), [IDEA] ENCR_CAST 6 (RFC 2451) ENCR_BLOWFISH 7 (RFC 2451) ENCR_3IDEA 8 (RFC 2451) ENCR_DES_IV32 9 Réservé 10 ENCR_NULL 11 (RFC 2410) ENCR_AES_CBC 12 (RFC 3602) ENCR_AES_CTR 13 (RFC 3664) Les valeurs 14 à 1023 snt réservées à l IANA. Les valeurs à snt à usage privé entre parties mutuellement cnsentantes. Pur le type 2 de transfrmatin (Fnctin pseud-aléatire), les identifiants de transfrmatin définis snt : Nm Numér Défini dans Réservé 0 PRF_HMAC_MD5 1 (RFC 2104), [RFC1321] PRF_HMAC_SHA1 2 (RFC 2104), [SHA] PRF_HMAC_TIGER 3 (RFC 2104) PRF_AES128_XCBC 4 (RFC 3664) Les valeurs 5 à 1023 snt réservées à l IANA. Les valeurs à snt à usage privé entre parties mutuellement cnsentantes. Pur le type 3 de transfrmatin (Algrithme d intégrité), les identifiants de transfrmatin définis snt : Nm Numér Défini dans Aucun 0 AUTH_HMAC_MD5_96 1 (RFC 2403) AUTH_HMAC_SHA1_96 2 (RFC 2404) AUTH_DES_MAC 3

30 RFC 4306 page Kaufman & autres AUTH_KPDK_MD5 4 (RFC 1828 AUTH_AES_XCBC_96 5 (RFC 3566) Les valeurs 6 à 1023 snt réservées à l IANA. Les valeurs snt à usage privé entre parties mutuellement cnsentantes. Pur le type 4 de transfrmatin (Grupe Diffie-Hellman), les identifiants de transfrmatin définis snt : Nm Numér Aucun 0 Défini à l appendice B 1 2 Réservé 3 4 Défini dans [RFC3526] 5 Réservé à l IANA 6 13 Défini dans [RFC3526] Réservé à l IANA Usage privé Pur le type 5 de transfrmatin (Numér de séquence étendu), les identifiants de transfrmatin définis snt : Nm Numér Pas de numér de séquence étendu 0 Numér de séquence étendu 1 Réservé Types de transfrmatin valides par prtcle Le nmbre et le type de transfrmatins qui accmpagnent une charge utile de SA dépendent du prtcle de la SA ellemême. Une charge utile de SA qui prpse l établissement d une SA a les types de transfrmatins bligatires et facultatifs suivants. Une mise en œuvre cnfrme DOIT cmprendre tus les types bligatires et facultatifs pur chaque prtcle qu elle accepte (bien qu elle n ait pas besin d accepter les prpsitins avec des suites inacceptables). Une prpsitin PEUT mettre les types facultatifs si la seule valeur qu elle puisse en accepter est Aucun. Prtcle Types bligatires Types facultatifs IKE ENCR, PRF, INTEG, D-H ESP ENCR, ESN INTEG, D-H AH INTEG, ESN D-H Identifiants de transfrmatins bligatires La spécificatin des suites qui DOIVENT et DEVRAIENT être prises en charge pur l interpérabilité a été retirée du présent dcument parce qu elles vnt vraisemblablement changer plus rapidement que le dcument lui-même. Une imprtante leçn tirée de IKEv1 est qu aucun système ne devrait seulement mettre en œuvre les algrithmes bligatires et s attendre à ce qu ils cnstituent le meilleur chix pur tus les cnsmmateurs. Par exemple, au mment de la rédactin du présent dcument, de nmbreux utilisateurs de IKEv1 cmmençaient à migrer vers AES en mde de chaînage de blc de chiffrement (CBC, Cipher Blck Chaining) pur les applicatins de réseau privé virtuel (VPN, Virtual Private Netwrk). De nmbreux systèmes IPsec fndés sur IKEv2 mettrnt en œuvre AES, des grupes Diffie-Hellman supplémentaires, et des algrithmes de hachage supplémentaires, et certains utilisateurs d IPsec exigent déjà ces algrithmes en plus de ceux figurant sur la liste ci-dessus. Il est vraisemblable que l IANA va ajuter des transfrmatins supplémentaires à l avenir, et certains utilisateurs peuvent vulir utiliser des suites privées, en particulier pur IKE ù les mises en œuvre devraient être capables de prendre en charge différents paramètres, jusqu à certaines limites de taille. À l appui de cet bjectif, tutes les mises en œuvre de IKEv2 DEVRAIENT inclure des facilités de gestin qui permettent la spécificatin (par un utilisateur u administrateur de système) de paramètres Diffie-Hellman (DH) (le générateur, le mdule, et les lngueurs et valeurs d expsant) pur les nuveaux grupes DH. Les mises en œuvre DEVRAIENT furnir une interface de gestin au myen de laquelle ces paramètres et les identifiants de transfrmatins assciées puissent être entrés (par un utilisateur u administrateur de système) pur permettre de négcier de tels grupes. Tutes les mises en œuvre de IKEv2 DOIVENT inclure une facilité de gestin qui permette à un utilisateur u administrateur de système de spécifier les suites dnt l utilisatin avec IKE est acceptable. À réceptin d une charge utile

31 RFC 4306 page Kaufman & autres avec un ensemble d identifiants de transfrmatins, la mise en œuvre DOIT cmparer les identifiants de transfrmatin transmis à ceux cnfigurés lcalement par les cntrôles de gestin, pur vérifier que la suite prpsée est acceptable sur la base d une plitique lcale. La mise en œuvre DOIT rejeter les prpsitins de SA qui ne snt pas autrisées par ces cntrôles de suite IKE. Nter que les suites cryptgraphiques qui DOIVENT être mises en œuvre n nt pas besin d être cnfigurées cmme acceptables pur la plitique lcale Attributs de transfrmatin Chaque transfrmatin dans une charge utile d assciatin de sécurité peut inclure des attributs qui mdifient u cmplètent la spécificatin de la transfrmatin. Ces attributs snt des paires de type/valeur et snt définis ci-dessus. Par exemple, si un algrithme de chiffrement a une clé de lngueur variable, la lngueur de clé à utiliser peut être spécifiée cmme un attribut. Les attributs peuvent avir une valeur d une lngueur fixe de deux ctets u une valeur de lngueur variable. Pur cette dernière, l attribut est cdé cmme type/lngueur/valeur (TLV) !A! Type d attribut! AF=0 Lngueur d attribut!!f AF=1 Valeur d attribut! ! AF=0 Valeur d attribut!! AF=1 Nn transmis! Figure 9 : Attributs de dnnées Type d attribut (2 ctets) Identifiant unique pur chaque type d attribut (vir ci-dessus). Le bit de plus frt pids de ce champ est le bit Frmat d attribut (AF). Il indique si les attributs de dnnées suivent le frmat de TLV u un frmat raccurci de type/valeur (TV). Si le bit AF est à zér (0), les attributs de dnnées snt alrs de la frme TLV. Si le bit AF est à un (1), les attributs de dnnées snt alrs de la frme type/valeur. Lngueur d attribut (2 ctets) - Lngueur en ctets de la valeur de l attribut. Quand le bit AF est à un (1), la valeur de l attribut est seulement de 2 ctets et le champ Lngueur d attribut n est pas présent. Valeur d attribut (lngueur variable) Valeur de l attribut asscié au type d attribut. Si le bit AF est à zér (0), ce champ a une lngueur de variable définie par le champ Lngueur d attribut. Si le bit AF est a un (1), la valeur d attribut a une lngueur de deux ctets. Nter qu un seul type d attribut (Lngueur de clé) est défini, et il est de lngueur fixe. La spécificatin de cdage de lngueur variable n est incluse que pur les extensins futures. Les seuls algrithmes définis dans le présent dcument qui acceptent des attributs snt le chiffrement fndé sur AES, l intégrité, et les fnctins pseud-aléatires, qui requièrent un seul attribut spécifiant la largeur de clé. Les attributs décrits cmme étant de base NE DOIVENT PAS être cdés en utilisant le cdage de lngueur variable. Les attributs de lngueur variable NE DOIVENT PAS être cdés cmme étant de base même si leur valeur peut tenir en deux ctets. NOTE : Ceci est un changement par rapprt à IKEv1, ù une suplesse accrue peut avir facilité la cmpsitin des messages mais a certainement cmpliqué l analyse. Type d attribut Valeur Frmat d attribut Réservé 0-13 Lngueur de clé (en bits) 14 TV Réservé Réservé à l IANA Usage privé Les valeurs 0 à 13 et 15 à 17 étaient utilisées dans un cntexte similaire dans IKEv1 et ne devraient pas être alluées sauf à des valeurs crrespndantes. Les valeurs 18 à snt réservées à l IANA. Les valeurs à snt pur usage privé entre des parties mutuellement cnsentantes. - Lngueur de clé Lrsqu n utilise un algrithme de chiffrement qui a une clé de lngueur variable, cet attribut spécifie la lngueur de clé en bits (DOIT utiliser l rdre des ctets du réseau). Cet attribut NE DOIT PAS être utilisé lrsque l algrithme de chiffrement spécifié utilise une clé de lngueur fixe.

32 RFC 4306 page Kaufman & autres Négciatin d attributs Durant la négciatin d assciatin de sécurité, les initiateurs présentent des ffres aux répndants. Les répndants DOIVENT chisir un seul ensemble cmplet de paramètres parmi les ffres (u rejeter tutes les ffres si aucune n est acceptable). Si il y a plusieurs prpsitins, le répndant DOIT chisir un seul numér de prpsitin et returner tutes les sus-structures de prpsitin avec ce numér de prpsitin. S il y a plusieurs transfrmatins du même type, le répndant DOIT en chisir une seule. Tut attribut d une transfrmatin chisie DOIT être returné nn mdifié. L initiateur d un échange DOIT vérifier que l ffre acceptée est chérente avec une de ses prpsitins, et sinn, cette répnse DOIT être rejetée. La négciatin des grupes Diffie-Hellman présente quelques défis particuliers. Les ffres de SA cmprtent les attributs prpsés et un numér public Diffie-Hellman (KE) dans le même message. Si dans l échange initial l initiateur ffre d utiliser un grupe Diffie-Hellman parmi plusieurs, il DEVRAIT prendre celui que le répndant va le plus vraisemblablement accepter et inclure un KE crrespndant à ce grupe. Si l hypthèse s avère être fausse, le répndant indiquera le grupe crrect dans la répnse et l initiateur DEVRAIT prendre un élément de ce grupe cmme valeur de sn KE lrsqu il réessaye le premier message. Cependant, il DEVRAIT cntinuer de prpser l ensemble des grupes qu il prend pleinement en charge afin d empêcher une attaque de dégradatin par interpsitin. Nte de mise en œuvre : Certains attributs négciables peuvent avir des gammes de valeurs acceptables u purraient avir plusieurs valeurs acceptables. Parmi elles figure la lngueur de clé d un chiffrement symétrique à lngueur de clé variable. Pur l interpérabilité future et pur prendre en charge de façn indépendante la remise à niveau des pints d extrémité, les dévelppeurs de ce prtcle DEVRAIENT accepter les valeurs dnt ils pensent qu elles furnissent une plus grande sécurité. Par exemple, si un hmlgue est cnfiguré pur accepter un chiffrement de lngueur variable avec une lngueur de clé de X bits et s il lui est ffert un chiffrement avec une plus grande lngueur de clé, la mise en œuvre DEVRAIT accepter l ffre si elle prend en charge la plus lngue clé. La prise en charge de cette capacité permet à une mise en œuvre d exprimer un cncept de "au mins" un certain niveau de sécurité -- "une lngueur de clé de _au_mins_ X bits pur le chiffrement Y". 3.4 Charge utile d échange de clés La charge utile d échange de clés, ntée KE dans le présent mémire, est utilisée pur échanger des nmbres publics Diffie-Hellman au titre d un échange de clés Diffie-Hellman. La charge utile d échange de clés cnsiste en un en-tête de charge utile générique IKE suivi par la valeur publique Diffie-Hellman elle-même !Prch. Ch. uti.!c! Réservé! Lngueur de charge utile! ! n de grupe DH! Réservé! ~ Dnnées d échange de clé ~ Figure 10 : Frmat de charge utile d échange de clés Une charge utile d échange de clés est cnstruite en cpiant une valeur publique Diffie-Hellman dans la prtin "Dnnées d échange de clés" de la charge utile. La lngueur de la valeur publique Diffie-Hellman DOIT être égale à la lngueur du principal mdule sur lequel l expnentiatin a été effectuée, en ajutant des bits à zér à l avant de la valeur si nécessaire. Le n de grupe DH identifie le grupe Diffie-Hellman dans lequel les dnnées d échange de clés nt été calculées (vir au paragraphe 3.3.2). Si la prpsitin chisie utilise un grupe Diffie-Hellman différent, le message DOIT être rejeté avec une charge utile Ntify du type INVALID_KE_PAYLOAD. Le type de charge utile pur la charge utile d échange de clés est trente quatre (34).

33 RFC 4306 page Kaufman & autres 3.5 Charges utiles d identificatin Les charges utiles d identificatin, ntées IDi et IDr dans le présent mémire, permettent aux hmlgues d attester mutuellement de leur identité. Cette identité peut être utilisée pur une recherche de plitique, mais n a pas nécessairement à crrespndre à quelque chse dans la charge utile CERT ; les deux champs peuvent être utilisés par une mise en œuvre pur prendre les décisins de cntrôle d accès. Nte : Dans IKEv1, deux charges utiles d identifiant étaient utilisées dans chaque directin pur détenir les infrmatins de sélecteurs de trafic (TS) pur les dnnées passant sur la SA. Dans IKEv2, ces infrmatins snt prtées dans les charges utiles de TS (vir au paragraphe 3.13). La charge utile d identificatin cnsiste en un en-tête générique de charge utile IKE suivi par les champs d identificatin : !Prch. Ch. uti.!c! Réservé! Lngueur de charge utile! ! Type d ID! Réservé ~ Dnnées d identificatin ~ Figure 11 : Frmat de charge utile d identificatin Type d identifiant (1 ctet) Spécifie le type d identificatin utilisée. Réservé - DOIT être envyé à zér ; DOIT être ignré à réceptin. Dnnées d identificatin (lngueur variable) - Valeur, cmme indiquée par le type d identificatin. La lngueur des dnnées d identificatin est calculée à partir de la taille dans l en-tête de charge utile d identificatin. Les types de charge utile pur la charge utile d identificatin snt trente cinq (35) pur IDi et trente six (36) pur IDr. Le tableau ci-après fait la liste des valeurs alluées pur le champ Type d identificatin, suivi par une descriptin des dnnées d identificatin qui viennent après : Type d identificatin Valeur Descriptin des dnnées Réservé 0 ID_IPV4_ADDR 1 Une seule adresse IPv4 de quatre (4) ctets ID_FQDN 2 Chaîne de nm de dmaine pleinement qualifié. Un exemple de aid_fqdn est "exemple.cm". La chaîne DOIT ne cntenir aucune terminaisn (par exemple, NULL, CR, etc.). ID_RFC822_ADDR 3 Chaîne d adresse de messagerie électrnique pleinement qualifiée de la RFC 822. Un exemple de ID_RFC822_ADDR est "[email protected]". La chaîne DOIT ne cntenir aucune terminaisn. Réservé à l IANA 4 ID_IPV6_ADDR 5 Une seule adresse IPv6 de seize (16) ctets. Réservé à l IANA 6 8 ID_DER_ASN1_DN 9 Le cdage binaire des règles de cdage distinctif (DER) d un nm distinctif X.500 en ASN.1 X.500 [X.501]. ID_DER_ASN1_GN 10 Le cdage binaire DER d un nm général X.500 en ASN.1 [X.509]. ID_KEY_ID 11 Flux d ctets paque qui peut être utilisé pur passer les infrmatins spécifiques du fabricant nécessaires pur faire certains types d identificatin brevetés. Réservé à l IANA Réservé à usage privé Deux mises en œuvre ne vnt interpérer que si chacune peut générer un type d ID acceptable pur l autre. Pur assurer une interpérabilité maximale, les mises en œuvre DOIVENT être cnfigurables pur envyer au mins une des

34 RFC 4306 page Kaufman & autres ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, u ID_KEY_ID, et DOIVENT être cnfigurables pur accepter tus ces types. Les mises en œuvre DEVRAIENT être capables de générer et d accepter tus ces types. Les mises en œuvre capables de IPv6 DOIVENT en plus être cnfigurables pur accepter ID_IPV6_ADDR. Les mises en œuvre qui n acceptent que IPv6 PEUVENT être cnfigurables pur envyer seulement ID_IPV6_ADDR. 3.6 Charge utile de certificat La charge utile de certificat, ntée CERT dans le présent mémire, dnne le myen de transprter des certificats u d autres infrmatins en relatin avec l authentificatin via IKE. Les charges utiles de certificat DEVRAIENT être incluses dans un échange si les certificats snt dispnibles pur l envyeur à mins que l hmlgue n ait indiqué sa capacité à restituer ces infrmatins à partir d ailleurs en utilisant une charge utile Ntify HTTP_CERT_LOOKUP_SUPPORTED. Nter que le terme "Charge utile de certificat" est quelque peu trmpeur, parce que tus les mécanismes d authentificatin n utilisent pas des certificats et que des dnnées autres que des certificats peuvent être passées dans cette charge utile. La charge utile de certificat est définie cmme suit : !Prch. Ch. uti.!c! Réservé! Lngueur de charge utile! ! Cd. certif ! ~ Dnnées de certificat ~ Figure 12 : Frmat de charge utile de certificat Cdage de certificat (1 ctet) Ce champ indique le type de certificat u d infrmatins se rapprtant au certificat cntenu dans le champ Dnnées de certificat. Cdage de certificat Valeur Réservé 0 Certificat X.509 envelppé dans PKCS n 7 1 Certificat PGP 2 Clé signée DNS 3 Certificat Signature X Jetn Kerbers 6 Liste de révcatin de certificats (CRL) 7 Liste de révcatin d autrité (ARL) 8 Certificat SPKI 9 Certificat Attribut X Clé RSA brute 11 Hachage et URL de certificat X Hachage et URL de faisceau X Réservé à l IANA Usage privé Dnnées de certificat (lngueur variable) Cdage réel des dnnées de certificat. Le type de certificat est indiqué par le champ Cdage de certificat. Le type de charge utile pur la charge utile de certificat est trente sept (37). La syntaxe spécifique de certains des cdes de type de certificat ci-dessus n est pas définie dans le présent dcument. Les types dnt la syntaxe est définie ici snt : Certificat - Signature X.509 (4) cntient un certificat X.509 cdé en DER dnt la clé publique est utilisée pur valider la charge utile AUTH de l envyeur. Liste de révcatin de certificat (7) cntient une liste de révcatin de certificats X.509 cdée en DER.

35 RFC 4306 page Kaufman & autres Clé RSA brute (11) cntient une clé RSA cdée en PKCS n 1 (vir [RSA] et [RFC3447]). Les cdages de hachage et d URL (12-13) permettent aux message IKE de rester curts en remplaçant les lngues structures de dnnées par un hachage SHA-1 de 20 ctets (vir [SHA]) de la valeur remplacée suivi par un URL de lngueur variable qui se résut en la structure de dnnées cdées en DER elle-même. Cela amélire l efficacité lrsque les pints d extrémité nt les dnnées de certificat en antémémire et rend IKE mins sujet aux attaques de déni de service qui deviennent plus faciles à mnter quand les messages IKE snt assez grs pur exiger la fragmentatin IP [KPS03]. Utiliser la définitin ASN.1 suivante pur un faisceau X.509 : CertBundle { is(1) identified-rganizatin(3) dd(6) internet(1) security(5) mechanisms(5) pkix(7) id-md(0) id-md-cert-bundle(34) } DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS Certificate, CertificateList FROM PKIX1Explicit88 { is(1) identified-rganizatin(3) dd(6) internet(1) security(5) mechanisms(5) pkix(7) id-md(0) id-pkix1-explicit(18) } ; CertificateOrCRL ::= CHOICE { cert [0] Certificate, crl [1] CertificateList } CertificateBundle ::= SEQUENCE OF CertificateOrCRL END Les mises en œuvre DOIVENT être capables d être cnfigurées pur envyer et accepter jusqu à quatre certificats X.509 à l appui de l authentificatin, et DOIVENT aussi être capables d être cnfigurées pur envyer et accepter les deux premiers frmats de hachage et d URL (avec des URL HTTP). Les mises en œuvre DEVRAIENT être capables d être cnfigurées pur envyer et accepter des clés RSA brutes. Si plusieurs certificats snt envyés, le premier certificat DOIT cntenir les clés publiques utilisées pur signer la charge utile AUTH. Les autres certificats peuvent être envyés dans n imprte quel rdre. 3.7 Charge utile de demande de certificat La charge utile Demande de certificat, ntée CERTREQ dans le présent mémire, furnit le myen de demander les certificats préférés via IKE et peut apparaître dans la répnse IKE_INIT_SA et/u la demande IKE_AUTH. Les charges utiles de demande de certificat PEUVENT être incluses dans un échange lrsque l envyeur a besin d btenir le certificat du receveur. Si plusieurs autrités de certificatin snt de cnfiance et si le cdage de certificat ne permet pas une liste, plusieurs charges utiles de demande de certificat DEVRAIENT être transmises. La charge utile Demande de certificat se définit cmme suit : !Prch. Ch. uti.!c! Réservé! Lngueur de charge utile! ! Cd. de certif ! ~ Autrité de certificatin ~ Figure 13 : Frmat de charge utile Demande de certificat Cdage de certificat (1 ctet) - Cntient un cdage du type u frmat du certificat demandé. La liste des valeurs figure au paragraphe 3.6.

36 RFC 4306 page Kaufman & autres Autrité de certificatin (lngueur variable) - Cntient un cdage d une autrité de certificatin acceptable pur le type de certificat demandé. Le type de charge utile pur la charge utile Demande de certificat est trente huit (38). Le champ cdage de certificat a les mêmes valeurs que celles définies au paragraphe 3.6. Le champ Autrité de certificatin cntient un indicateur des autrités de cnfiance pur ce type de certificat. La valeur de Autrité de certificatin est une liste cncaténée de hachages SHA-1 des clés publiques des autrités de certificatin (CA) de cnfiance. Chacune est cdée cmme hachage SHA-1 de l élément Infrmatin de clé publique sujette (Subject Public Key Inf) (vir au paragraphe de la RFC 3280) à partir de chaque certificat d ancre de cnfiance. Les hachages de vingt ctets snt enchaînés et inclus sans autre frmatage. Nter que le terme "Demande de certificat" est quelque peu trmpeur, en ce que des valeurs autres que de certificats snt définies dans une charge utile de "Certificat" et les demandes pur ces valeurs peuvent être présentes dans une charge utile de demande de certificat. La syntaxe de la charge utile de demande de certificat pur de tels cas n est pas définie ici. La charge utile de demande de certificat est traitée en inspectant le champ "Cdage de certificat" pur déterminer si le prcesseur dispse de certificats de ce type. Si c est le cas, le champ "Autrité de certificatin" est inspecté pur déterminer si le prcesseur dispse d un certificat qui puisse être validé jusqu à une des autrités de certificatin spécifiées. Cela peut être une chaîne de certificats. Si un certificat d entité terminale existe, qui satisfasse aux critères spécifiés dans le CERTREQ, un certificat u chaîne de certificats DEVRAIT être renvyé au demandeur de certificat si le receveur du CERTREQ : - est cnfiguré pur utiliser l authentificatin de certificat, - est autrisé à envyer une charge utile CERT, - a une plitique d autrité de certificat de cnfiance qui guverne la négciatin en curs, et - a au mins un chaînage de certificat d entité terminale apprprié en temps et en usage avec une autrité de certificat furnie dans le CERTREQ. La vérificatin des révcatins de certificat dit être envisagée durant le prcessus de chaînage utilisé pur chisir un certificat. Nter que même si deux hmlgues snt cnfigurés pur utiliser deux autrités de certificat différentes, les relatins de certificatin crisée devraient être acceptées par une lgique de chix apprpriée. Le but n est pas d empêcher la cmmunicatin par la stricte adhésin au chix d un certificat fndé sur CERTREQ, alrs qu un certificat de remplacement purrait être chisi par l envyeur qui permettrait aussi au receveur de réussir à le valider en cnfiance au myen de la certificatin crisée, des CRL, u d autres myens cnfigurés hrs bande. Et dnc, le traitement d un CERTREQ devrait être vu cmme la suggestin d un chix de certificat plutôt qu une bligatin. S il n existe pas de certificat, le CERTREQ est alrs ignré. Ceci n est pas une cnditin d erreur du prtcle. Il peut y avir des cas ù il y a une CA préférée envyée dans le CERTREQ, mais une autre purrait être acceptable (peut-être après appel à un pérateur humain). 3.8 Charge utile d authentificatin La charge utile d authentificatin, ntée AUTH dans le présent mém, cntient des dnnées utilisées pur les besins de l authentificatin. La syntaxe des dnnées d authentificatin varie cnfrmément à la méthde d authentificatin cmme spécifié ci-dessus. La charge utile d authentificatin est définie cmme suit : !Prch. Ch. uti.!c! Réservé! Lngueur de charge utile! !Méthde d auth.! Réservé! ~ Dnnées d authentificatin ~ Figure 14 : Frmat de charge utile d authentificatin Méthde d authentif. (1 ctet) Spécifie la méthde d authentificatin utilisée. Les valeurs définies snt :

37 RFC 4306 page Kaufman & autres Signature numérique RSA (1) Calculée cmme spécifié au paragraphe 2.15 en utilisant une clé privée RSA sur un hachage burré de PKCS n 1 (VOIR [RSA] et [RFC3447]). Cde d intégrité de message à clé partagée (2) Calculé cmme spécifié au paragraphe 2.15 en utilisant la clé partagée assciée à l identité dans la charge utile d identifiant et la fnctin prf négciée. Signature numérique DSS (3) Calculée cmme spécifié au paragraphe 2.15 en utilisant une clé privée DSS (vir [DSS]) sur un hachage SHA-1. Les valeurs 0 et 4 à 200 snt réservées à l IANA. Les valeurs 201 à 255 snt dispnibles pur usage privé. Dnnées d authentificatin (lngueur variable) - vir au paragraphe Le type de charge utile pur la charge utile d authentificatin est trente neuf (39). 3.9 Charge utile de nm ccasinnel La charge utile de nm ccasinnel, ntée Ni et Nr dans le présent mémire pur le nm ccasinnel respectivement de l initiateur et du répndant, cntient des dnnées aléatires utilisées pur garantir le maintien en vie durant un échange et prtéger cntre les attaques en répétitin. La charge utile de nm ccasinnel se définit cmme suit : !Prch. Ch. uti.!c! Réservé! Lngueur de charge utile! ~ Dnnées du nm ccasinnel ~ Figure 15 : Frmat de charge utile de nm ccasinnel Dnnées de nm ccasinnel (lngueur variable) Cntient les dnnées aléatires générées par l entité émettrice. Le type de charge utile pur la charge utile de nm ccasinnel est quarante (40). La taille d un nm ccasinnel DOIT être entre 16 et 256 ctets inclus. Les valeurs de nm ccasinnel NE DOIVENT PAS être réutilisées Charge utile de Ntificatin La charge utile Ntificatin, ntée N dans le présent dcument, est utilisée pur transmettre des dnnées d infrmatin, telles que les cnditins d erreur et les transitins d état, à un hmlgue IKE. Une charge utile Ntificatin peut apparaître dans un message de répnse (spécifiant habituellement purqui une demande a été rejetée), dans un échange INFORMATIONAL (pur rapprter une erreur en dehrs d une demande IKE), u dans tut autre message pur indiquer les capacités de l envyeur u pur mdifier la significatin de la demande. La charge utile Ntificatin se définit cmme suit : !Prch. Ch. uti.!c! Réservé! Lngueur de charge utile! ! ID prtcle! Taille du SPI! Type du message Ntifier! ~ Indice de paramètre de décurité (SPI) ~

38 RFC 4306 page Kaufman & autres ~ Dnnées de ntificatin ~ Figure 16 : Frmat de charge utile Ntificatin ID de prtcle (1 ctet) Si cette ntificatin cncerne une SA existante, ce champ indique le type de cette SA. Pur les ntificatins IKE_SA, ce champ DOIT être un (1). Pur les ntificatins cncernant les SA IPsec, ce champ DOIT cntenir (2) pur indiquer AH u (3) pur indiquer ESP. Pur les ntificatins qui ne se rapprtent pas à une SA existante, ce champ DOIT être mis à zér et DOIT être ignré à réceptin. Tutes les autres valeurs de ce champ snt réservées à l IANA pur de futures allcatins. Taille de SPI (1 ctet) Lngueur en ctets du SPI tel que défini par l identifiant de prtcle IPsec u zér si aucun SPI n est applicable. Pur une ntificatin cncernant la IKE_SA, la taille de SPI DOIT être zér. Type de Message Ntify (2 ctets) Spécifie le type de message de ntificatin. SPI (lngueur variable) I ndice de paramètre de sécurité. Dnnées de ntificatin (lngueur variable) Dnnées d infrmatin u d erreur transmises en plus du type de message Ntify. Les valeurs pur ce champ snt spécifiques du type (vir ci-dessus). Le type de charge utile pur la charge utile de ntificatin est quarante et un (41) Types de message Ntify Les infrmatins de ntificatin peuvent être des messages d erreur qui spécifient purqui une SA ne purrait être établie. Elles peuvent aussi être des dnnées d état qu un prcessus de gestin d une base de dnnées de SA suhaite cmmuniquer à un prcessus hmlgue. Le tableau ci-dessus fait la liste des messages de ntificatin et de leurs valeurs crrespndantes. Le numér des différents états d erreur a été cnsidérablement réduit depuis IKEv1 à la fis dans un suci de simplificatin et pur éviter de dnner des infrmatins de cnfiguratin d'infrmatin aux sndeurs. Les types qui snt dans la gamme de 0 à snt destinés à rapprter les erreurs. Une mise en œuvre recevant une charge utile Ntify avec un de ces types qu elle ne recnnaît pas dans une répnse DOIT suppser que la demande crrespndante a échué entièrement. Les types d erreur nn recnnus dans une demande et les types d état dans une demande u répnse DOIVENT être ignrés sauf qu ils DEVRAIENT être enregistrés dans un jurnal. Les charges utiles Ntify avec des types d état PEUVENT être ajutées à tut message et DOIVENT être ignrées si elles ne snt pas recnnues. Elles snt destinées à indiquer des capacités, et au titre de la négciatin de SA, elles snt utilisées pur négcier les paramètres nn cryptgraphiques. Messages NOTIFY Types d erreur Valeur Réservé 0 UNSUPPORTED_CRITICAL_PAYLOA 1 D (charge utile critique nn acceptée) Envyé si la charge utile a le bit "critique" mis et si le type de charge utile n est pas recnnu. Les dnnées de ntificatin cntiennent le type de charge INVALID_IKE_SPI (SPI IKE invalide) INVALID_MAJOR_VERSION (versin majeure invalide) utile d un ctet. 4 Indique qu un message IKE a été reçu avec un SPI de destinatin incnnue. Cela indique habituellement que le receveur s est réinitialisé et a ublié l existence d une IKE_SA. 5 Indique que le receveur ne peut pas traiter la versin d IKE spécifiée dans l en-tête. Le plus prche numér de versin que le receveur peut accepter sera dans l en-tête de répnse.

39 RFC 4306 page Kaufman & autres INVALID_SYNTAX (syntaxe invalide) INVALID_MESSAGE_ID (identifiant de message invalide) INVALID_SPI (indice de paramètre de sécurité invalide) NO_PROPOSAL_CHOSEN (aucune prpsitin chisie) INVALID_KE_PAYLOAD (charge utile KE invalide) AUTHENTICATION_FAILED (échec d authentificatin) SINGLE_PAIR_REQUIRED (une seule paire exigée) NO_ADDITIONAL_SAS (pas de SA supplémentaire) INTERNAL_ADDRESS_FAILURE (échec d adresse interne) FAILED_CP_REQUIRED (exige échec de charge utile de cnfig.) TS_UNACCEPTABLE (sélecteur de trafic inacceptable) 7 Indique que le message IKE reçu est invalide parce que un type, lngueur, u valeur est hrs gamme u parce que la demande a été rejetée pur des raisns de plitique. Pur éviter une attaque de déni de service utilisant des messages falsifiés, cet état ne peut être returné que pur et dans un paquet chiffré si l ID de message et la smme de cntrôle cryptgraphique étaient valides. Pur éviter des fuites d infrmatins au prfit d un sndeur du nœud, cet état DOIT être envyé en répnse à tute erreur nn cuverte par un des autres types d état. Pur aider à la recherche d erreurs, des infrmatins d erreur détaillées DEVRAIENT être écrites à la cnsle u dans le jurnal de brd. 9 Envyé lrsque est reçu un identifiant de message IKE en dehrs de la fenêtre acceptée. Cette ntificatin NE DOIT PAS être envyée dans une répnse ; il NE DOIT PAS y avir d accusé de réceptin de la demande invalide. On infrme à la place l autre côté en initialisant un échange INFORMATIONAL avec les dnnées de ntificatin qui cntiennent les quatre ctets d identifiant du message invalide. L envi de cette ntificatin est facultatif, et les ntificatins de ce type DOIVENT être limitées en débit. 11 PEUVENT être envyés dans un échange IKE INFORMATIONAL lrsque un nœud reçit un paquet ESP u AH avec un SPI invalide. Les dnnées de ntificatin cntiennent le SPI du paquet invalide. Cela indique habituellement qu un nœud s est réinitialisé et a ublié une SA. Si ce message d infrmatin est envyé en dehrs du cntexte d une IKE_SA, il ne devrait être utilisé par le receveur que cmme une "alerte" sur une anmalie pssible (parce que ce purrait facilement être une manipulatin). 14 Aucune des suites de chiffrement prpsées n est acceptable. 17 Le champ n de grupe D-H dans la charge utile KE n est pas le n de grupe chisi par le répndant pur cet échange. Il y a deux ctets de dnnées assciées à cette ntificatin : le n de grupe D-H accepté, en rdre grs butien. 24 Envyé dans la répnse à un message IKE_AUTH lrsque l authentificatin a échué pur une raisn quelcnque. Il n y a pas de dnnées assciées. 34 Cette erreur indique qu une demande CREATE_CHILD_SA est inacceptable parce que sn envyeur veut accepter seulement des sélecteurs de trafic spécifiant une seule paire d adresses. On s attend à ce que le demandeur répnde en demandant une SA pur le seul trafic spécifique qu il essaye de transmettre. 35 Cette erreur indique qu une demande CREATE_CHILD_SA est inacceptable parce que le répndant ne veut pas accepter d autres CHILD_SA sur cette IKE_SA. Certaines mises en œuvre minimales peuvent n accepter l établissement que d une seule CHILD_SA dans le cntexte d un échange IKE initial et rejeter tute tentative d ajut ultérieur. 36 Indique une erreur d allcatin d adresse interne (c est-à-dire, INTERNAL_IP4_ADDRESS u INTERNAL_IP6_ADDRESS) durant le traitement d une charge utile de cnfiguratin par un répndant. Si cette erreur est générée au sein d un échange IKE_AUTH, aucune CHILD_SA ne sera créée. 37 Envyé par le répndant dans le cas ù CP(CFG_REQUEST) est attendu mais pas reçu, et dnc en cnflit avec la plitique lcale cnfigurée. Il n y a pas de dnnées assciées. 38 Indique qu aucune des adresses/prtcles/accès des sélecteurs de trafic furnis n est acceptable.

40 RFC 4306 page Kaufman & autres INVALID_SELECTORS (sélecteurs invalides) 39 PEUT être envyé dans un échange IKE INFORMATIONAL lrsqu un nœud reçit un paquet ESP u AH dnt les sélecteurs de trafic ne crrespndent pas à ceux de la SA sur laquelle il a été livré (et cela a causé l abandn du paquet). Les dnnées de ntificatin cntiennent le début du paquet en cause (cmme dans les messages ICMP) et le champ SPI de la ntificatin est réglé de façn à crrespndre au SPI de la SA IPsec. Réservé à l IANA Types d erreur Usage privé Erreurs Messages NOTIFY Types d état Valeur INITIAL_CONTACT Cette ntificatin affirme que cette IKE_SA est la seule IKE_SA actuellement active entre les identités authentifiées. Elle PEUT être envyée quand une IKE_SA est établie après une défaillance, et le receveur PEUT utiliser cette infrmatin pur supprimer tutes les autres IKE_SA qu il a pur la même identité authentifiée sans attendre une fin de temprisatin. Cette ntificatin NE DOIT PAS être envyée par une entité qui peut être dupliquée (par exemple, des accréditifs d utilisateur en itinérance lrsque l usager est autrisé à se cnnecter au pare-feu d entreprise à partir de deux systèmes distants au même mment). SET_WINDOW_SIZE Cette ntificatin affirme que le pint d extrémité d envi est capable de garder l état pur plusieurs échanges en curs, permettant au receveur d envyer plusieurs demandes avant d btenir une répnse à la première. Les dnnées assciées à une ntificatin SET_WINDOW_SIZE DOIVENT être lngues de 4 ctets et cntenir la représentatin en grs butien du nmbre de messages que l envyeur prmet de garder. La taille de fenêtre est tujurs de un jusqu à la fin de l échange initial. ADDITIONAL_TS_POSSIBLE Cette ntificatin affirme que le pint d extrémité d envi a rétréci les sélecteurs de trafic prpsés mais que d autres sélecteurs de trafic seraient aussi acceptables, quique seulement dans une SA distincte (vir au paragraphe 2.9). Il n y a pas de dnnées assciées à ce type de ntificatin. Elle ne peut être envyée que cmme charge utile supplémentaire dans un message incluant les TS acceptés. IPCOMP_SUPPORTED Cette ntificatin ne peut être incluse que dans un message cntenant une charge utile de SA négciant une CHILD_SA et indique la vlnté de l envyeur d utiliser IPCmp sur cette SA. Les dnnées assciées à cette ntificatin incluent un CPI IPCmp de deux ctets suivi par un identifiant de transfrmatin d un ctet suivi facultativement par des attributs dnt la lngueur et le frmat snt définis par cet identifiant de transfrmatin. Un message prpsant une SA peut cntenir plusieurs ntificatins IPCOMP_SUPPORTED pur indiquer plusieurs algrithmes acceptés. Un message acceptant une SA peut en cntenir au plus une. Les identifiants de transfrmatin actuellement définis snt : Nm Numér Défini dans Réservé 0 IPCOMP_OUI 1 IPCOMP_DEFLATE 2 RFC 2394 IPCOMP_LZS 3 RFC 2395 IPCOMP_LZJH 4 RFC 3051 Les valeurs 5 à 240 snt réservées à l IANA. Les valeurs 241 à 255 snt pur utilisatin privée entre des parties mutuellement cnsentantes.

41 RFC 4306 page Kaufman & autres NAT_DETECTION_SOURCE_IP (détectin de NAT sur la surce IP) NAT_DETECTION_DESTINATION_IP (détectin de NAT sur la destinatin IP) COOKIE (témin) USE_TRANSPORT_MODE (utiliser le mde transprt) HTTP_CERT_LOOKUP_SUPPORTED (recherche de certificat HTTP acceptée) REKEY_SA (renuvellement de clés de SA) ESP_TFC_PADDING_NOT_SUPPORTE D (burrage TFC EFC nn accepté) NON_FIRST_FRAGMENTS_ALSO (aussi des fragments nn premiers) Cette ntificatin est utilisée par sn receveur pur déterminer si la surce est derrière un NAT. Les dnnées assciées à cette ntificatin snt un résumé SHA-1 des SPI (dans l rdre dans lequel ils apparaissent dans l en-tête), de l adresse IP, et de l'accès sur lequel ce paquet a été envyé. Il PEUT y avir plusieurs charges utiles Ntify de ce type dans un message si l envyeur ne sait pas lequel des rattachements réseau sera utilisé pur envyer le paquet. Le receveur de cette ntificatin PEUT cmparer la valeur furnie au hachage SHA-1 des SPI, adresse IP de surce, et accès, et si ils ne crrespndent pas, il DEVRAIT activer la traversée de NAT (vir au paragraphe 2.23). Autrement, il PEUT rejeter la tentative de cnnexin si la traversée de NAT n est pas acceptée Cette ntificatin est utilisée par sn receveur pur déterminer si elle est derrière un NAT. Les dnnées assciées à cette ntificatin snt un résumé SHA-1 des SPI (dans l rdre dans lequel ils apparaissent dans l en-tête), de l adresse IP, et de l'accès auquel le paquet est envyé. Le receveur de cette ntificatin PEUT cmparer la valeur furnie à un hachage des SPI, de l adresse de destinatin IP, et de l'accès, et si ils ne crrespndent pas, il DEVRAIT invquer la traversée de NAT (vir au paragraphe 2.23). Si il s ne crrespndent pas, cela signifie que cette extrémité est derrière un NAT et cette extrémité DEVRAIT cmmencer l envi de paquets de maintien en vie cmme défini dans la [RFC3948]. Autrement, il PEUT rejeter la tentative de cnnexin si la traversée de NAT n est pas acceptée Cette ntificatin PEUT être incluse dans une répnse IKE_SA_INIT. Elle indique que la demande devrait être réessayée avec une cpie de cette ntificatin cmme première charge utile. Cette ntificatin DOIT être incluse dans un nuvel essai de demande IKE_SA_INIT si une ntificatin COOKIE était incluse dans la répnse initiale. Les dnnées assciées à cette ntificatin DOIVENT être entre 1 et 64 (inclus) ctets de lng Cette ntificatin PEUT être incluse dans un message de demande qui inclut aussi une charge utile SA demandant une CHILD_SA. Elle demande que la CHILD_SA utilise le mde transprt plutôt que le mde tunnel pur la SA créée. Si la demande est acceptée, la répnse DOIT aussi inclure une ntificatin du type USE_TRANSPORT_MODE. Si le répndant refuse la demande, la CHILD_SA sera établie en mde tunnel. Si ce n est pas acceptable pur l initiateur, celui-ci DOIT supprimer la SA. Nte : Excepté lrs de l utilisatin de cette ptin pur négcier le mde transprt, tutes les CHILD_SA vnt utiliser le mde tunnel. Nte : Les mdificatins de désencapsulatin ECN spécifiées dans la [RFC4301] DOIVENT être effectuées pur chaque SA en mde tunnel créée par IKEv Cette ntificatin PEUT être incluse dans tut message qui peut inclure une charge utile CERTREQ et indiquer que l envyeur est capable de rechercher des certificats sur la base d URL fndés sur HTTP (et dnc suppsé préférer recevir des spécificatins de certificat dans ce frmat) Cette ntificatin DOIT être incluse dans un échange CREATE_CHILD_SA si l bjet de l échange est de remplacer une SA ESP u AH existante. Le champ SPI identifie la SA dnt n renuvelle les clés. Il n y a pas de dnnées Cette ntificatin affirme que le pint d extrémité d envi NE VA PAS accepter de paquets cntenant le burrage de cnfidentialité de flux (TFC) Utilisé pur le cntrôle de fragmentatin. Vir l explicatin dans la [RFC4301].

42 RFC 4306 page Kaufman & autres Réservé à l IANA Types d état Usage privé - Types d état Charge utile Delete La charge utile Delete (supprimer), ntée D dans le présent mémire, cntient un identifiant d assciatin de sécurité spécifique du prtcle que l envyeur a retiré de sa base de dnnées d assciatin de sécurité et n est dnc plus valide. La Figure 17 mntre le frmat de la charge utile Delete. Il est pssible d envyer plusieurs SPI dans une charge utile Delete ; cependant, chaque SPI DOIT être pur le même prtcle. Le mélange d identifiants de prtcle NE DOIT PAS être effectué dans une charge utile Delete. Il est cependant permis d inclure plusieurs charges utiles Delete dans un seul échange INFORMATIONAL ù chaque charge utile Delete fait la liste des SPI pur un prtcle différent. La suppressin de la IKE_SA est indiquée par un ID de prtcle de 1 (IKE) mais pas de SPI. La suppressin d une CHILD_SA, telle que ESP u AH, cntiendra l ID de prtcle IPsec de ce prtcle (2 pur AH, 3 pur ESP), et le SPI est celui que le pint d extrémité d envi attendrait dans les paquets ESP u AH entrants. La charge utile Delete se définit cmme suit : !Prch. Ch. uti.!c! Réservé! Lngueur de charge utile! ! ID prtcle! Taille du SPI! Nmbre de SPI! ~ Indices de paramètres de sécurité (SPI) ~ Figure 17 : Frmat de charge utile Delete ID de prtcle (1 ctet) - Dit être 1 pur une IKE_SA, 2 pur AH, u 3 pur ESP. Taille de SPI (1 ctet) Lngueur en ctets du SPI cmme défini par l ID du prtcle. Il DOIT être zér pur IKE (le SPI est dans l en-tête de message) u quatre pur AH et ESP. Nmbre de SPI (2 ctets) - Le nmbre de SPI cntenus dans la charge utile Delete. La taille de chaque SPI est définie par le champ Taille de SPI. Indice(s) de paramètre de sécurité (SPI) (lngueur variable) Identifie la u les assciatins de sécurité spécifiques à supprimer. La lngueur de ce champ est déterminée par les champs Taille de SPI et Nmbre de SPI. Le type de charge utile pur la charge utile Delete est quarante deux (42) Charge utile d identifiant de fabricant La charge utile ID de fabricant, ntée V dans le présent mémire, cntient une cnstante définie par le fabricant. La cnstante est utilisée par le fabricant pur identifier et recnnaître à distance ses instances de mise en œuvre. Ce mécanisme permet à un fabricant d expérimenter de nuveaux dispsitifs tut en maintenant la rétr cmpatibilité. Une charge utile ID de fabricant PEUT annncer que l envyeur est capable d accepter certaines extensins du prtcle, u elle PEUT simplement identifier la mise en œuvre pur une aide à la recherche d erreurs. Plusieurs charges utiles ID de fabricant PEUVENT être envyées. Une mise en œuvre N EST PAS OBLIGÉE d envyer du tut de charge utile ID de fabricant. Une charge utile ID de fabricant peut être envyée au titre de tut message. La réceptin d une charge utile ID de fabricant familière permet à une mise en œuvre de faire usage des numérs à usage privé décrits tut au lng du présent mémire -- charges utiles privées, échanges privés, ntificatins privées, etc. Les identifiants de fabricant nn familiers DOIVENT être ignrés. Les auteurs de prjets Internet qui suhaitent étendre le présent prtcle DOIVENT définir une charge utile ID de fabricant pur annncer la capacité à mettre en œuvre l extensin dans le prjet Internet. Il est prévu que les prjets Internet qui snt acceptés et snt nrmalisés recevrnt des "numérs magiques" hrs de la gamme Utilisatin future de la part de l IANA, et l exigence d utiliser un identifiant de fabricant sera abandnnée.

43 RFC 4306 page Kaufman & autres Les champs de charge utile ID de fabricant snt définis cmme suit : !Prch. Ch. uti.!c! Réservé! Lngueur de charge utile! ~ Identifiant de fabricant (VID) ~ Figure 18 : Frmat de charge utile d identifiant de fabricant Identifiant de fabricant (lngueur variable) Il est de la respnsabilité de la persnne qui chisit l identifiant de fabricant de s assurer de sn unicité en dépit de l absence de tut registre central des identifiants. Il est de bnne pratique d inclure le nm de la cmpagnie, un nm de persnne, u quelque chse cmme cela. Si vus vulez épater, vus puvez inclure la latitude, la lngitude et l heure qu il était quand vus avez chisi l identifiant et un nmbre aléatire. Un résumé de message en une lngue chaîne unique est préférable à la lngue chaîne unique elle-même. Le type de charge utile pur la charge utile d identifiant de fabricant est quarante tris (43) Charge utile de sélecteur de trafic La charge utile de sélecteur de trafic, ntée TS dans le présent mémire, permet aux hmlgues d identifier les flux de paquet pur le traitement par les services de sécurité IPsec. La charge utile de sélecteur de trafic cmprte l en-tête générique IKE de charge utile suivi par les sélecteurs de trafic individuels cmme suit : !Prch. Ch. uti.!c! Réservé! Lngueur de charge utile! ! Nmbre de TS! Réservé! ~ <Sélecteurs de trafic> ~ Figure 19 : Frmat de charge utile de sélecteur de trafic Nmbre de TS (1 ctet) Nmbre de sélecteurs de trafic furnis. Réservé Ce champ DOIT être envyé à zér et DOIT être ignré à réceptin. Sélecteurs de trafic (lngueur variable) - Un u plusieurs sélecteurs de trafic individuels. La lngueur de la charge utile de sélecteur de trafic inclut l en-tête TS et tus les sélecteurs de trafic. Le type de charge utile pur la charge utile de sélecteur de trafic est quarante quatre (44) pur les adresses du côté initiateur de la SA et quarante cinq (45) pur les adresses du côté répndant Sélecteur de trafic ! Type de TS!ID prtcleip* Lngueur de sélecteur

44 RFC 4306 page Kaufman & autres Accès de début * Accès de fin * ~ Adresse de début * ~ ~ Adresse de fin * ~ Figure 20 : Sélecteur de trafic * Nte : Tus les champs autres que Type de TS et Lngueur de sélecteur dépendent du Type de TS. Le champ mntré est pur les types de TS 7 et 8, deux seules valeurs actuellement définies. Type de TS (un ctet) Spécifie le type de sélecteur de trafic. ID de prtcle IP (1 ctet) - Valeur qui spécifie un ID de prtcle IP asscié (par exemple, UDP/TCP/ICMP). Une valeur de zér signifie que l ID de prtcle n est pas pertinent pur ce sélecteur de trafic -- la SA peut prter tus les prtcles. Lngueur de sélecteur Spécifie la lngueur de cette sus structure de sélecteur de trafic y cmpris l en-tête. Accès de début (2 ctets) Valeur qui spécifie le plus petit numér de l'accès admis par ce sélecteur de trafic. Pur les prtcles pur lesquels l'accès est indéfini, u si tus les accès snt permis, ce champ DOIT être zér. Pur le prtcle ICMP, les deux champs Type et Cde d un ctet snt traités cmme un seul numér d'accès entier de 16 bits (avec Type dans les huit bits de plus frt pids et Cde dans les huit bits de mindre pids) pur les besins du filtrage fndé sur ce champ. Accès de fin (2 ctets) - Valeur qui spécifie le plus grand numér d'accès admis par ce sélecteur de trafic. Pur les prtcles pur lesquels l'accès est indéfini, u si tus les accès snt permis, ce champ DOIT être Pur le prtcle ICMP, les deux champs Type et Cde d un ctet snt traités cmme un seul numér d'accès entier de 16 bits (avec Type dans les huit bits de plus frt pids et Cde dans les huit bits de mindre pids) pur les besins du filtrage fndé sur ce champ. Adresse de début La plus petite adresse incluse dans ce sélecteur de trafic (lngueur déterminée par le type de TS). Adresse de fin La plus grande adresse incluse dans ce sélecteur de trafic (lngueur déterminée par le type de TS). Les systèmes qui se cnfrment à la [RFC4301] et suhaitent indiquer "TOUT" accès DOIVENT régler l'accès de début à 0 et l'accès de fin à ; nter que cnfrmément à la [RFC4301], "TOUT" inclut "OPAQUE". Les systèmes qui fnctinnent avec la [RFC4301] et suhaitent indiquer un accès "OPAQUE", mais pas "TOUT" accès, DOIVENT régler l'accès de début à et l'accès de fin à 0. Le tableau suivant fait la liste des valeurs alluées pur le champ Type de sélecteur de trafic et les dnnées de sélecteur d adresse crrespndantes. Type de TS Valeur Réservé 0 à 6 TS_IPV4_ADDR_RANG 7 E Gamme d adresses IPv4, représentées par deux valeurs de quatre ctets. La première valeur est l adresse IPv4 de début (incluse) et la secnde valeur est l adresse IPv4 de fin (incluse). Tutes les adresses tmbant entre les deux adresses spécifiées snt cnsidérées cmme TS_IPV6_ADDR_RANG E Réservé à l IANA 9 à 240 Usage privé 241 à 255 étant à l intérieur de la liste. 8 Gamme d adresses IPv6, représentées par deux valeurs de quatre ctets. La première valeur est l adresse IPv4 de début (incluse) et la secnde valeur est l adresse IPv6 de fin (incluse). Tutes les adresses tmbant entre les deux adresses spécifiées snt cnsidérées cmme étant à l intérieur de la liste Charge utile chiffrée La charge utile chiffrée, ntée SK{...} u E dans le présent mémire, cntient d autres charges utiles en frme chiffrée. La charge utile Chiffrée, si elle est présente dans un message, DOIT être la dernière charge utile du message. Suvent, elle est la seule charge utile du message.

45 RFC 4306 page Kaufman & autres Les algrithmes de chiffrement et de prtectin d intégrité snt négciés durant l établissement de la IKE_SA, et les clés snt calculées cmme spécifié aux paragraphes 2.14 et Les algrithmes de chiffrement et de prtectin d intégrité snt mdélisés d après les algrithmes ESP décrits dans les [RFC2104], [RFC4303], et [RFC2451]. Le présent dcument spécifie entièrement le traitement cryptgraphique des dnnées IKE, mais ces dcuments devraient être cnsultés par les cncepteurs d algrithmes. On exige un blc de chiffrement d une taille de blc fixe et un algrithme de vérificatin d intégrité qui calcule une smme de cntrôle de lngueur fixe sur un message de taille variable. Le type de charge utile pur une charge utile Chiffrée est quarante six (46). La charge utile chiffrée cmprte l en-tête générique de charge utile IKE suivi par des champs individuels cmme suit : !Prch. Ch. uti.!c! Réservé! Lngueur de charge utile! ! Vecteur d initialisatin!!(lngueur est la taille de blc pur l algrithme de chiffmt.)! ~ Charges utiles IKE chiffrées ~ Burrage (0-255 ctets)! Lng. burrage! ~ Dnnées de smme de cntrôle d intégrité ~ Figure 21 : Frmat de charge utile Chiffrée Prchaine charge utile - Type de charge utile de la première charge utile incrprée. Nter que c est une exceptin dans le frmat d en-tête standard, car la charge utile Chiffrée est la dernière charge utile du message et dnc le champ Prchaine charge utile devrait nrmalement être à zér. Mais cmme le cntenu de cette charge utile est fait de charges utiles incrprées et qu il n y a pas d emplacement naturel ù placer le type de la première, ce type est placé ici. Lngueur de charge utile Inclut les lngueurs de l en-tête, IV, charges utiles IKE Chiffrées, Burrage, Lngueur de burrage, et dnnées de smme de cntrôle d intégrité. Vecteur d initialisatin - Valeur chisie de façn aléatire dnt la lngueur est égale à la lngueur de blc de l algrithme de chiffrement sus-jacent. Les receveurs DOIVENT accepter tute valeur. Les envyeurs DEVRAIENT sit prendre cette valeur pseud-aléatire et indépendante pur chaque message, sit utiliser le blc de chiffrement final du message envyé précédent. Les envyeurs NE DOIVENT PAS utiliser la même valeur pur chaque message, ni utiliser une séquence de valeurs avec une faible distance de Hamming (par exemple, un numér de séquence), u utiliser du texte chiffré d un message reçu. Les charges utiles IKE snt cmme spécifié plus haut dans cette sectin. Ce champ est chiffré avec un chiffre négcié. Le burrage PEUT cntenir tute valeur chisie par l envyeur, et DOIT avir une lngueur qui cmbine les charges utiles, le burrage, et la lngueur de burrage en un multiple de la taille du blc de chiffrement. Ce champ est chiffré avec le chiffre négcié. Lngueur de burrage est la lngueur du champ Burrage. L envyeur DEVRAIT régler la lngueur de burrage à la valeur minimum qui fait de la cmbinaisn des charges utiles, du burrage, et de la lngueur de burrage un multiple de la taille de blc, mais le receveur DOIT accepter tute lngueur qui dnne un alignement apprprié. Ce champ est chiffré avec le chiffre négcié. Dnnées de smme de cntrôle d intégrité est la smme de cntrôle cryptgraphique sur le message entier, qui cmmence à l en-tête IKE fixe jusqu à la Lngueur de burrage. La smme de cntrôle DOIT être calculée sur le message chiffré. Sa lngueur est déterminée par l algrithme d intégrité négcié.

46 RFC 4306 page Kaufman & autres 3.15 Charge utile de cnfiguratin La charge utile Cnfiguratin, ntée CP dans le présent dcument, est utilisée pur échanger des infrmatins de cnfiguratin entre hmlgues IKE. L échange sert à un IRAC à demander une adresse IP interne à un IRAS et à échanger d autres infrmatins de même srte qu il purrait acquérir avec le prtcle de cnfiguratin d hôte dynamique (DHCP, Dynamic Hst Cnfiguratin Prtcl) si l IRAC était directement cnnecté à un LAN. Les charges utiles Cnfiguratin snt du type CFG_REQUEST/CFG_REPLY u CFG_SET/CFG_ACK (vir le type CFG dans la descriptin de charge utile ci-dessus). Les charges utiles CFG_REQUEST et CFG_SET peuvent facultativement être ajutées à tute demande IKE. La répnse IKE DOIT inclure une charge utile CFG_REPLY u CFG_ACK u Ntify crrespndante, avec un type d erreur qui indique purqui la demande n a pas pu être hnrée. Une exceptin est qu une mise en œuvre minimale PEUT ignrer tutes les charges utiles CFG_REQUEST et CFG_SET, aussi un message de répnse sans CFG_REPLY u CFG_ACK crrespndante DOIT être accepté cmme une indicatin que la demande n a pas été acceptée. "CFG_REQUEST/CFG_REPLY" permet à un pint d extrémité IKE de demander des infrmatins à sn hmlgue. Si un attribut dans la charge utile de cnfiguratin CFG_REQUEST n est pas de lngueur zér, il est pris cmme une suggestin pur cet attribut. La charge utile de cnfiguratin CFG_REPLY PEUT returner cette valeur, u une nuvelle. Elle PEUT aussi ajuter de nuveaux attributs et ne pas inclure certains de ceux demandés. Les demandeurs DOIVENT ignrer les attributs returnés qu ils ne cnnaissent pas. Certains attributs PEUVENT être multi-valeurs, auquel cas plusieurs stuctures d attribut de cnfiguratin du même type snt envyées et/u returnées. Généralement, tutes les valeurs d un attribut snt returnées lrsque l attribut est demandé. Pur certains attributs (seules des adresses internes dans la présent versin de la spécificatin) plusieurs demandes indiquent une demande à laquelle plusieurs valeurs snt alluées. Pur ces attributs, le nmbre des valeurs returnées NE DEVRAIT PAS excéder le nmbre demandé. Si le type de dnnées demandées dans une CFG_REQUEST n est pas recnnu u pas accepté, le répndant NE DOIT PAS returner un type d erreur mais DOIT plutôt, sit envyer une CFG_REPLY qui PEUT être vide, sit une répnse qui ne cntient pas de charge utile CFG_REPLY du tut. Les returs d erreurs snt réservés aux cas ù la demande est recnnue mais ne peut pas être traitée cmme demandé u ù la demande est mal frmatée. "CFG_SET/CFG_ACK" permet à un pint d extrémité IKE de pusser les dnnées de cnfiguratin jusqu à sn hmlgue. Dans ce cas, la charge utile de cnfiguratin CFG_SET cntient des attributs que l initiateur veut vir sn hmlgue altérer. Le répndant DOIT returner une charge utile de cnfiguratin s il accepte une des dnnées de cnfiguratin et elle DOIT cntenir les attributs que le répndant a acceptés avec des dnnées de lngueur zér. Ces attributs qu il n a pas acceptés NE DOIVENT PAS être dans la charge utile de cnfiguratin CFG_ACK. Si aucun attribut n a été accepté, le répndant DOIT returner une charge utile CFG_ACK u un message de répnse sans charge utile CFG_ACK. Il n y a actuellement pas d utilisatin définie de l échange CFG_SET/CFG_ACK, bien qu il puisse être utilisé en cnnexin avec des extensins fndées sur les identifiants de fabricant. Une mise en œuvre minimale de la présente spécificatin PEUT ignrer les charges utiles CFG_SET. Des extensins via la charge utile CP NE DEVRAIENT PAS être utilisées pur de la gestin tut venant. Sa principale destinatin est de furnir un mécanisme d amrçage pur des échanges d infrmatins au sein d IPsec d IRAS à IRAC. Alrs qu il PEUT être utile d utiliser une telle méthde pur échanger des infrmatins entre certaines passerelles de sécurité u petits réseaux, les prtcles de gestin existants tels que [RFC2131], [RFC2865], SNMP, u [RFC2251] devraient être préférés pur la gestin d entreprise aussi bien que pur les échanges d infrmatin ultérieurs. La charge utile Cnfiguratin est définie cmme suit : !Prch. Ch. uti.!c! Réservé! Lngueur de charge utile! ! Type de CFG! Réservé! ~ Attributs de cnfiguratin ~ Figure 22 : Frmat de charge utile Cnfiguratin

47 RFC 4306 page Kaufman & autres Le type de charge utile pur la charge utile de cnfiguratin est quarante sept (47). Type de CFG (1 ctet) - Type d échange représenté par les attributs de cnfiguratin. Type de CFG Valeur Réservé 0 CFG_REQUEST 1 CFG_REPLY 2 CFG_SET 3 CFG_ACK 4 Les valeurs 5 à 127 snt réservées à l IANA. Les valeurs 128 à 255 snt pur usage privé entre des parties mutuellement cnsentantes. Réservé (3 ctets) - DOIT être envyé à zér; DOIT être ignré à réceptin. Attributs de cnfiguratin (lngueur) Ce snt des valeurs de lngueur de type spécifiques de la charge utile de cnfiguratin et elles snt définies ci-dessus. Il peut y avir zér, un u plusieurs attributs de cnfiguratin dans cette charge utile Attributs de cnfiguratin !R Type d attribut! Lngueur ~ Valeur ~ Figure 23 : Frmat d attributs de cnfiguratin Réservé (1 bit) - Ce bit DOIT être mis à zér et DOIT être ignré à réceptin. Type d attribut (15 bits) - Identifiant unique pur chaque type d attribut de cnfiguratin. Lngueur (2 ctets) - Lngueur en ctets de la valeur. Valeur (0 ctet u plus) Valeur de lngueur variable de cet attribut de cnfiguratin. Les types d attribut suivants nt été définis : Type d attribut Valeur Multi-valrisé Lngueur Réservé 0 INTERNAL_IP4_ADDRESS 1 ui* 0 u 4 ctets INTERNAL_IP4_NETMASK 2 nn 0 u 4 ctets INTERNAL_IP4_DNS 3 ui 0 u 4 ctets INTERNAL_IP4_NBNS 4 ui 0 u 4 ctets INTERNAL_ADDRESS_EXPIRY 5 nn 0 u 4 ctets INTERNAL_IP4_DHCP 6 ui 0 u 4 ctets APPLICATION_VERSION 7 nn 0 u plus INTERNAL_IP6_ADDRESS 8 ui* 0 u 17 ctets Réservé 9 INTERNAL_IP6_DNS 10 ui 0 u 16 ctets INTERNAL_IP6_NBNS 11 ui 0 u 16 ctets INTERNAL_IP6_DHCP 12 ui 0 u 16 ctets INTERNAL_IP4_SUBNET 13 ui 0 u 8 ctets SUPPORTED_ATTRIBUTES 14 nn multiple de 2 INTERNAL_IP6_SUBNET 15 ui 17 ctets * Ces attributs ne peuvent être multi-valrisés au retur que si des valeurs multiples étaient demandées.

48 RFC 4306 page Kaufman & autres Les types 16 à snt réservés à IANA. Les valeurs snt pur usage privé entre parties mutuellement cnsentantes. INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS Adresse sur le réseau interne, parfis appelée adresse de nœud ruge u adresse privée et PEUT être une adresse privée sur l Internet. Dans un message de demande, l adresse spécifiée est une adresse demandée (u zér si aucune adresse spécifique n est demandée). Si une adresse spécifique est demandée, elle indique vraisemblablement qu une cnnexin antérieure existait avec cette adresse et que le demandeur aimerait réutiliser cette adresse. Avec IPv6, un demandeur PEUT furnir les ctets d adresse de faible pids qu il veut utiliser. Plusieurs adresses internes PEUVENT être demandées en demandant plusieurs attributs d adresse interne. Le répndant PEUT envyer au maximum le nmbre d adresses demandées. INTERNAL_IP6_ADDRESS est cmpsé de deux champs : le premier est une adresse IPv6 de seize ctets et le secnd est une lngueur de préfixe d un ctet cmme défini dans la [RFC3513]. L adresse demandée n est valide que jusqu à l expiratin du délai défini par l attribut INTERNAL_ADDRESS EXPIRY u bien il n y a pas de IKE_SA entre les hmlgues. INTERNAL_IP4_NETMASK Gabarit de réseau du réseau interne. Un seul gabarit de réseau est admis dans la demande et les messages de répnse (par exemple, ), et il DOIT être utilisé uniquement avec un attribut INTERNAL_IP4_ADDRESS. INTERNAL_IP4_DNS, INTERNAL_IP6_DNS Spécifie une adresse de serveur DNS au sein du réseau. Plusieurs serveurs DNS PEUVENT être requis. Le répndant PEUT répndre par zér un u plusieurs attributs de serveur DNS. INTERNAL_IP4_NBNS, INTERNAL_IP6_NBNS - Spécifie une adresse d un serveur de nm NetBis (WINS) au sein du réseau. Plusieurs serveurs NBNS PEUVENT être requis. Le répndant PEUT répndre avec zér un u plusieurs attributs de serveur NBNS. INTERNAL_ADDRESS_EXPIRY Spécifie le nmbre de secndes pendant lesquelles l hôte peut utiliser l adresse IP interne. L hôte DOIT renuveler l adresse IP avant l expiratin de ce délai. Un seul de ces attributs PEUT être présent dans la répnse. INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP Ordnne à l hôte d envyer tute demande DHCP interne cntenue au sein de cet attribut. Plusieurs serveurs DHCP PEUVENT être nécessaires. Le répndant PEUT répndre par zér un u plusieurs attributs de serveur DHCP. APPLICATION_VERSION Infrmatins de versin u d applicatin de l hôte IPsec. C est une chaîne de caractères ASCII imprimables qui N EST PAS terminée par le caractère NUL. INTERNAL_IP4_SUBNET Les sus-réseaux prtégés par ce dispsitif de brdure. Cet attribut est cmpsé de deux champs : le premier est une adresse IP et le secnd un gabarit de réseau. Plusieurs sus-réseaux PEUVENT être demandés. Le répndant PEUT répndre avec zér un u plusieurs attributs de sus réseau. SUPPORTED_ATTRIBUTES Lrsqu il est utilisé au sein d une demande, cet attribut DOIT être de lngueur zér et spécifie une interrgatin à laquelle le répndant dit répndre avec tus les attributs qu il accepte. La répnse cntient un attribut qui cntient un ensemble d identifiants d attribut ayant chacun 2 ctets. La lngueur divisée par 2 (ctets) établit le nmbre d attributs acceptés cntenus dans la répnse. INTERNAL_IP6_SUBNET - Les sus-réseaux prtégés par ce dispsitif de brdure. Cet attribut est cmpsé de deux champs : le premier est une adresse IPv6 de seize ctets et le secnd est une lngueur de préfixe d un ctet cmme défini dans la [RFC3513]. Plusieurs sus-réseaux PEUVENT être demandés. Le répndant PEUT répndre avec zér, un, u plusieurs attributs de sus-réseau. Nter que le présent dcument ne fait aucune recmmandatin sur la façn dnt une mise en œuvre affiche réellement les infrmatins à envyer dans une répnse. C est à dire que nus ne recmmandns aucune méthde spécifique seln laquelle un IRAS détermine quel serveur DNS devrait être returné à un IRAC demandeur Charge utile de prtcle d authentificatin extensible (EAP) La charge utile de prtcle d authentificatin extensible, ntée EAP dans le présent mémire, permet aux IKE_SA d être authentifiées en utilisant le prtcle défini dans la [RFC3748] et les extensins ultérieures à ce prtcle. L ensemble cmplet des valeurs acceptables pur la charge utile est défini ailleurs, mais un bref résumé de la RFC3748 est inclus ici

49 RFC 4306 page Kaufman & autres pur rendre le présent dcument autnme dans les cas les plus curants !Prch. Ch. uti.!c! Réservé! Lngueur de charge utile! ~ Message EAP ~ Figure 24 : Frmat de charge utile EAP Le type de charge utile pur une charge utile EAP est quarante huit (48) ! Cde! Identifiant! Lngueur!! Type! Dnnées_de_type Figure 25 : Frmat de message EAP Cde (1 ctet) indique si ce message est une Demande (1), Répnse (2), Succès (3), u Échec (4). Identifiant (1 ctet) est utilisé dans PPP pur distinguer les messages répétés frauduleusement de ceux répétés nrmalement. Cmme dans IKE, EAP fnctinne sur un prtcle fiable, il n a ici aucune fnctin. Dans un message de répnse, cet ctet DOIT être établi pur crrespndre à l identifiant dans la demande crrespndante. Dans les autres messages, ce champ PEUT être réglé à n imprte quelle valeur. Lngueur (2 ctets) est la lngueur du message EAP et DOIT être inférieur de quatre à la Lngueur de charge utile de la charge utile qui l incrpre. Type (1 ctet) n est présent que si le champ Cde est Demande (1) u Répnse (2). Pur les autres cdes, la lngueur de message EAP DOIT être de quatre ctets et les champs Type et Dnnées_de_type NE DOIVENT PAS être présents. Dans un message Demande (1), Type indique les dnnées qui snt demandées. Dans un message Répnse (2), Type DOIT être sans accusé de réceptin u crrespndre au type des dnnées demandées. Les types suivants snt définis dans la RFC3748 : 1 Identité 2 Ntificatin 3 Pas d accusé de réceptin (uniquement en répnse) 4 Défi MD5 5 Mt de passe à utilisatin unique (OTP, One-Time Passwrd) 6 Carte de jetn générique Dnnées_de_type (Lngueur variable) varie avec le type de demande et la répnse assciée. Pur la dcumentatin sur les méthdes d EAP, vir [RFC3748]. Nter que dans la mesure ù IKE passe une indicatin de l identité de l initiateur dans le message 3 du prtcle, le répndant NE DEVRAIT PAS envyer de demande d identité EAP. L initiateur DEVRAIT, cependant, répndre à de telles demandes si il en reçit. 4 Exigences de cnfrmité Afin de garantir l interpérabilité de tutes les mises en œuvre de IKEv2, il y a des exigences supplémentaires aux "DOIT prendre en charge" qui snt énumérés ailleurs. Bien sûr, IKEv2 est un prtcle de sécurité, et une de ses fnctins majeures est de ne permettre qu aux parties autrisées de réussir l établissement cmplet des assciatins de sécurité. Ainsi une mise en œuvre particulière peut être cnfigurée avec un nmbre quelcnque de restrictins cncernant les algrithmes

50 RFC 4306 page Kaufman & autres et les autrités de cnfiance qui empêchernt une interpérabilité universelle. IKEv2 est cnçu pur permettre des mises en œuvre minimales qui peuvent interpérer avec les mises en œuvre cnfrmes à la ttalité de ses prescriptins. Il y a une série de dispsitifs facultatifs qui peuvent aisément être ignrés par une mise en œuvre particulière si elle ne prend pas en charge ce dispsitif. Ces dispsitifs snt : - la capacité à négcier des SA à travers un NAT et à tunneler la SA ESP résultante sur UDP. - la capacité à demander (et à répndre à une demande) d adresse IP tempraire à l extrémité distante d un tunnel. - la capacité à prendre en charge divers types d authentificatin traditinnels. - la capacité à prendre en charge des tailles de fenêtre supérieures à un. - la capacité à établir plusieurs SA ESP et/u AH au sein d une seule IKE_SA. - la capacité à renuveler les clés des SA. Pur assurer l interpérabilité, tutes les mises en œuvre DOIVENT être capables d analyser tus les types de charge utile (éventuellement pur les sauter) et d ignrer les types de charge utile qu elles ne prennent pas en charge sauf si le bit critique est établi dans l en-tête de charge. Si le bit critique est établi dans un en-tête de charge utile nn pris en charge, tutes les mises en œuvre DOIVENT rejeter les messages cntenant ces charges utiles. Tute mise en œuvre DOIT être capable d effectuer les échanges des quatre messages IKE_SA_INIT et IKE_AUTH qui établissent deux SA (un pur IKE, un pur ESP et/u AH). Les mises en œuvre PEUVENT être en initiatin seule u en répnse seule si c est apprprié pur leur plate-frme. Tute mise en œuvre DOIT être capable de répndre à un échange INFORMATIONAL, mais une mise en œuvre minimale PEUT répndre à tut message INFORMATIONAL par une répnse INFORMATIONAL vide (nter que dans le cntexte d une IKE_SA, un message "vide" cnsiste en un en-tête IKE suivi par une charge utile Chiffrée sans charge utile à l intérieur). Une mise en œuvre minimale ne PEUT prendre en charge l échange CREATE_CHILD_SA que pur autant qu elle recnnaît les demandes et les rejette avec une charge utile Ntify du type NO_ADDITIONAL_SAS Une mise en œuvre minimale n a pas besin d être capable d initier les échanges CREATE_CHILD_SA u INFORMATIONAL. Lrsqu une SA arrive à expiratin (sur la base de valeurs cnfigurées lcalement de durée de vie u d ctets passés) une mise en œuvre PEUT essayer de la renuveler avec un échange CREATE_CHILD_SA u elle PEUT supprimer (fermer) la vieille SA et en créer une nuvelle. Si le répndant rejette la demande CREATE_CHILD_SA avec une ntificatin NO_ADDITIONAL_SAS, la mise en œuvre DOIT être capable de clre la vieille SA et d en créer une nuvelle à la place. Les mises en œuvre ne snt pas bligées de prendre en charge la demande d adresses IP tempraires u de répndre à de telles demandes. Si une mise en œuvre n accepte pas de prduire de telles demandes, elle DOIT inclure une charge utile CP dans le message 3, cntenant au mins un champ de type INTERNAL_IP4_ADDRESS u INTERNAL_IP6_ADDRESS. Tus les autres champs snt facultatifs. Si une mise en œuvre accepte de répndre à de telles demandes, elle DOIT analyser la charge utile CP de type CFG_REQUEST dans le message 3 et recnnaître un champ de type INTERNAL_IP4_ADDRESS u INTERNAL_IP6_ADDRESS. Si elle accepte de prêter une adresse du type apprprié, elle DOIT returner une charge utile CP de type CFG_REPLY cntenant une adresse du type demandé. Le répndant DEVRAIT inclure tus les autres attributs qui s y rapprtent s il en a. Une mise en œuvre IPv4 répndante minimale ignrera le cntenu de la charge utile CP sauf pur déterminer qu elle cmprte un attribut INTERNAL_IP4_ADDRESS et répndra avec l adresse et les autres attributs qui s y rapprtent que l initiateur les ait demandés u nn. Une mise en œuvre IPv4 d initiateur minimale génèrera une charge utile CP ne cntenant qu un attribut INTERNAL_IP4_ADDRESS et analysera la répnse en ignrant cet attribut si elle ne sait pas cmment l utiliser. Le seul attribut qu elle DOIT être capable de traiter est INTERNAL_ADDRESS_EXPIRY, qu elle dit utiliser pur limiter la durée de vie de la SA sauf si elle réussit à renuveler le bail avant sn expiratin. Les initiateurs minimaux n nt pas besin d être capables de demander un renuvellement de bail et les répndants minimaux n nt pas besin d y répndre. Pur qu une mise en œuvre puisse être dite cnfrme à la présente spécificatin, il DOIT être pssible de la cnfigurer pur qu elle accepte ce qui suit : - des certificats PKIX cntenant, et signés par, des clés RSA d une taille de 1024 u 2048 bits, ù l identifiant passé est un ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, u ID_DER_ASN1_DN. - une authentificatin de clé partagée ù l identifiant passé est un ID_KEY_ID, ID_FQDN, u une ID_RFC822_ADDR. - une authentificatin ù le répndant est authentifié en utilisant des certificats PKIX et ù l initiateur est authentifié en utilisant l authentificatin de clé partagée. 5 Cnsidératins sur la sécurité Bien que ce prtcle sit cnçu pur minimiser la divulgatin des infrmatins de cnfiguratin aux hmlgues nn authentifiés, certaines divulgatins snt inévitables. Un hmlgue u l autre dit s identifier le premier et pruver d abrd sn identité. Pur éviter les investigatins, l initiateur d un échange est bligé de s identifier en premier, et

51 RFC 4306 page Kaufman & autres habituellement il est aussi bligé de s authentifier en premier. L initiateur peut cependant apprendre que le répndant prend en charge IKE ainsi que les prtcles cryptgraphiques qu il accepte. Le répndant (u quelqu un qui se fait passer pur le répndant) peut snder l initiateur nn seulement sur sn identité, mais en utilisant des charges utiles CERTREQ, peut être capable de déterminer quels certificats l initiateur veut utiliser. L utilisatin de l authentificatin EAP change quelque peu les pssibilités d investigatin. Lrsque l authentificatin EAP est utilisée, le répndant pruve sn identité avant l initiateur, ainsi un initiateur qui cnnaît le nm d un initiateur valide purrait snder le répndant à la fis sur sn nm et ses certificats. Un renuvellement de clés répété en utilisant CREATE_CHILD_SA sans échange Diffie-Hellman supplémentaire laisse tutes les SA vulnérables à l analyse cryptgraphique d une seule clé u à la subversin d un des pints d extrémité. Les dévelppeurs devraient nter le fait et mettre une limite aux échanges CREATE_CHILD_SA entre expnentiatins. Le présent mémire ne prescrit pas une telle limite. La frce d une clé déduite d un échange Diffie-Hellman utilisant un des grupes définis ici dépend de la frce inhérente du grupe, de la taille des expsants utilisés, et de l entrpie furnie par le générateur de nmbres aléatires utilisé. Du fait de ces éléments, il est difficile de déterminer la frce d une clé pur un grupe défini. Le grupe Diffie-Hellman numér deux, utilisé avec un frt générateur de nmbres aléatires et un expsant qui n est pas inférieur à 200 bits, est d usage curant avec 3DES. Le grupe cinq dnne une plus grande sécurité que le grupe deux. Le grupe un n a plus d intérêt qu histrique et ne dnne pas une frce suffisante en dehrs de sn utilisatin avec DES, qui est lui aussi cmplètement dépassé. Les mises en œuvre devraient nter ces évaluatins pur établir des plitiques et négcier des paramètres de sécurité. Nter que ces limitatins snt sur les grupes Diffie-Hellman eux-mêmes. Il n y a rien dans IKE qui interdise d utiliser des grupes plus frts, ni rien qui dilue la frce btenue de grupes plus frts (limitée par la frce des autres algrithmes négciés, y cmpris la fnctin pseud aléatire). En fait, le cadre extensible d IKE encurage à la définitin de plus de grupes ; l utilisatin de grupes à curbe elliptique peut accrître grandement la frce tut en utilisant des nmbres beaucup plus petits. On suppse que tus les expsants Diffie-Hellman snt effacés des mémires après usage. En particulier, ces expsants NE DOIVENT PAS être déduits de secrets à lngue durée de vie cmme la racine d un générateur pseud-aléatire qui n est pas effacée après usage. La frce de tutes les clés est limitée par la taille du résultat de la fnctin prf négciée. Pur cette raisn, une fnctin prf dnt le résultat est inférieur à 128 bits (par exemple, 3DES-CBC) NE DOIT PAS être utilisée avec ce prtcle. La sécurité de ce prtcle est très dépendante du caractère aléatire des paramètres chisis de façn aléatire. Ceux-ci devraient être générés par une surce frtement aléatire sus une surce pseud-aléatire avec une graine apprpriée (vir la RFC 4086). Les dévelppeurs devraient veiller à s assurer que l utilisatin de nmbres aléatires à la fis pur les clés et pur les nms ccasinnels est agencée d une façn qui ne mette pas en péril la sécurité des clés. Pur des infrmatins sur les mtivatins de beaucup des chix de cnceptins cryptgraphiques du présent prtcle, vir [SIGMA] et [SKEME]. Bien que la sécurité des CHILD_SA négciées ne dépende pas de la frce du chiffrement et de la prtectin d intégrité négciées dans la IKE_SA, les mises en œuvre NE DOIVENT PAS négcier NONE cmme algrithme IKE de prtectin d intégrité u ENCR_NULL cmme algrithme IKE de chiffrement. Lrs de l utilisatin de clés pré-partagées, une cnsidératin critique est d assurer le caractère aléatire de ces secrets. La pratique la plus frte est de s assurer qu aucune clé pré-partagée ne cntient autant d aléa que la plus frte clé en négciatin. Déduire un secret partagé d un mt de passe, d un nm, u autre surce à faible entrpie n est pas sûr. Ces surces snt susceptibles d attaques de dictinnaire et d ingénierie sciale, entre autres. Les ntificatins NAT_DETECTION_*_IP cntiennent un hachage des adresses et accès pur essayer de dissimuler les adresses IP internes qui snt derrière un NAT. Cmme l espace d adresse IPv4 est seulement de 32 bits, et qu il est habituellement très clairsemé, il serait pssible à un attaquant de décuvrir l adresse interne utilisée derrière le NAT en essayant tutes les adresses IP pssibles et en essayant de truver le hachage crrespndant. Les numérs d'accès snt nrmalement fixés à 500, et les SPI peuvent être extraits du paquet. Cela réduit le nmbre de calculs de hachages à 2^32. Avec de bnnes hypthèses sur l utilisatin de l espace d adresses privées, le nmbre de calculs de hachage est bien plus faible. Les cncepteurs ne devraient dnc pas suppser que l utilisatin de IKE ne va pas dnner lieu à des fuites d infrmatins des adresses internes. Lrsqu n utilise une méthde d authentificatin EAP qui ne génère pas une clé partagée pur prtéger une charge utile AUTH ultérieure, certaines attaques par interpsitin et par travestissement du serveur snt pssibles [EAPMITM]. Ces faiblesses surviennent lrsque EAP est aussi utilisé dans des prtcles qui ne snt pas prtégés avec un tunnel sûr.

52 RFC 4306 page Kaufman & autres Cmme EAP est un prtcle d authentificatin tut venant, qui est suvent utilisé pur furnir des facilités à une seule signature, le dévelppement d une slutin IPsec s appuyant sur une méthde d authentificatin EAP qui ne génère pas une clé partagée (aussi appelée une méthde EAP à nn génératin de clé) peut être cmprmise du fait du dévelppement d une applicatin entièrement nn crrélée qui va aussi arriver à utiliser la même méthde EAP à nn génératin de clé, mais de façn nn prtégée. Nter que cette faiblesse n est pas limitée seulement à EAP, mais peut survenir dans d autres scénaris ù une infrastructure d authentificatin est réutilisée. Par exemple, si le mécanisme EAP utilisé par IKEv2 utilise un authentifiant à jetns, une attaque par interpsitin purrait se faire passer pur le serveur de la Tile, intercepter l échange de jetns d authentificatin, et l utiliser pur initier une cnnexin IKEv2. Pur cette raisn, l utilisatin de méthdes EAP à nn génératin de clé DEVRAIT être évitée autant que pssible. Lrsqu elles snt utilisées, il est extrêmement imprtant que tute usage de ces méthdes EAP DEVRAIT utiliser un tunnel prtégé, ù l initiateur valide le certificat du répndant avant d initier l échange EAP. Les dévelppeurs DEVRAIENT décrire les faiblesses de l utilisatin des méthdes EAP à nn génératin de clé dans la dcumentatin de leurs mises en œuvre de façn que les administrateurs qui dévelppent des slutins IPsec sient cnscients de ses dangers. Une mise en œuvre utilisant EAP DOIT aussi utiliser une authentificatin fndée sur la clé publique du serveur auprès du client avant le début de l échange EAP, même si la méthde EAP ffre l authentificatin mutuelle. Cela évite d avir des variatins de prtcle IKEv2 supplémentaires et prtège les dnnées EAP cntre les attaques actives. Si les messages de IKEv2 snt assez lngs pur que la fragmentatin de niveau IP sit nécessaire, il est pssible que des attaques puissent empêcher l achèvement de l échange en saturant les mémires tampn de réassemblage. Les chances de réussite d une telle attaque peuvent être minimisées en utilisant les cdages de hachage et d URL au lieu d envyer les certificats (vir au paragraphe 3.6). Des mesures supplémentaires snt expsées dans [KPS03]. 6 Cnsidératins relatives à l IANA Le présent dcument définit un certain nmbre de nuveaux types et valeurs de champs pur lesquels des allcatins futures sernt gérées par l IANA. Les registres suivants nt été créés par l IANA: IKEv2 Exchange Types (paragraphe 3.1) IKEv2 Paylad Types (paragraphe 3.2) IKEv2 Transfrm Types (paragraphe 3.3.2) IKEv2 Transfrm Attribute Types (paragraphe 3.3.2) IKEv2 Encryptin Transfrm IDs (paragraphe 3.3.2) IKEv2 Pseud-randm Functin Transfrm IDs (paragraphe 3.3.2) IKEv2 Integrity Algrithm Transfrm IDs (paragraphe 3.3.2) IKEv2 Diffie-Hellman Transfrm IDs (paragraphe 3.3.2) IKEv2 Identificatin Paylad ID Types (paragraphe 3.5) IKEv2 Certificate Encdings (paragraphe 3.6) IKEv2 Authenticatin Methd (paragraphen 3.8) IKEv2 Ntify Message Types (paragraphen ) IKEv2 Ntificatin IPCOMP Transfrm IDs (paragraphe ) IKEv2 Security Prtcl Identifiers (paragraphe 3.3.1) IKEv2 Traffic Selectr Types (paragraphe ) IKEv2 Cnfiguratin Paylad CFG Types (paragraphe 3.15) IKEv2 Cnfiguratin Paylad Attribute Types (paragraphe ) Nte : Un nuveau registre dit être créé lrs de la créatin d un nuveau type de transfrmatin. Les changements et ajuts à un de ces registres snt sumis à révisin par experts. 7 Remerciements Le présent dcument est le résultat de la cllabratin de l ensemble du grupe de travail IPsec. Si le nmbre des auteurs qui peuvent figurer sur une RFC n était pas limité, vici ceux qui y figureraient, par rdre alphabétique : Bill Aiell, Stephane Beaulieu, Steve Bellvin, Sara Bitan, Matt Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hffman, Jhn Iannidis, Charlie Kaufman, Steve Kent, Angels Kermytis, Ter Kivinen, Hug Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer Reingld, et Michael Richardsn. De nmbreuses autres persnnes nt cntribué à sa cnceptin. Il s agit d une évlutin de IKEv1, d ISAKMP, et du DOI IPsec, dnt chacun a sa prpre liste d auteurs. Hugh Daniel a suggéré le

53 RFC 4306 page Kaufman & autres dispsitif par lequel l initiateur, dans le message 3, spécifie un nm pur le répndant, et a dnné à ce dispsitif le jli nm de "Ti Tarzan, mi Jane". David Faucher et Valery Smyzlv nt aidé à préciser le cncept de négciatin de sélecteur de trafic. 8 Références 8.1 Références nrmatives [RFC2119] S. Bradner, "Mts clés à utiliser dans les RFC pur indiquer les niveaux d'exigence", BCP 14, mars [RFC2434] T. Narten et H. Alvestrand, "Lignes directrices pur la rédactin d'une sectin Cnsidératins relatives à l'iana dans les RFC", BCP 26, ctbre, (Rendue bslète par la RFC 5226) [RFC2451] R. Pereira, R. Adams, "Algrithmes de chiffrement ESP en mde CBC", nvembre (P.S.) [RFC3168] K. Ramakrishnan et autres, "Ajut de la ntificatin explicite d'encmbrement (ECN) à IP", septembre (P.S.) [RFC3280] R. Husley, W. Plk, W. Frd et D. Sl, "Prfil de certificat d'infrastructure de clé publique X.509 et de liste de révcatin de certificat (CRL) pur l'internet", avril (Obslète, vir RFC5280) [RFC3513] R. Hinden et S. Deering, "Architecture d'adressage du prtcle Internet versin 6 (IPv6)", avril (Obs. vir RFC4291) [RFC3526] T. Kivinen et M. Kj, "Grupes supplémentaires d expnentiatin mdulaire (MODP) Diffie-Hellman pur l échange de clés Internet (IKE)", mai [RFC3748] B. Abba et autres, "Prtcle extensible d'authentificatin ", juin (P.S., MàJ par RFC5247) [RFC3948] A. Huttunen et autres, "Encapsulatin UDP de paquets ESP d'ipsec", janvier (P.S.) [RFC4301] S. Kent et K. Se, "Architecture de sécurité pur le prtcle Internet", décembre (P.S.) (Remplace la RFC2401) 8.2 Références infrmatives [DES] ANSI X3.106, "American Natinal Standard fr Infrmatin Systems-Data Link Encryptin", American Natinal Standards Institute, [DH] W. Diffie et M. Hellman, "New Directins in Cryptgraphy", IEEE Transactins n Infrmatin Thery, V. IT-22, n. 6 juin [DSS] NIST, "Digital Signature Standard", FIPS 186, Natinal Institute f Standards et Technlgy, U.S. Department f Cmmerce, mai [EAPMITM] N. Askan, V. Nierni et K. Nyberg, "Man-in-the-Middle in Tunneled Authenticatin Prtcls", nvembre [IDEA] X. Lai, "On the Design et Security f Blck Ciphers," ETH Series dans Infrmatin Prcessing, v. 1, Knstanz: Hartung-Grre Verlag, [KPS03] [PK01] C. Kaufman, R. Perlman et B. Smmerfeld, "DS prtectin fr UDP-based prtcls", Cnférence ACM sur la sécurité infrmatique et des cmmunicatins, ctbre R. Perlman et C. Kaufman, "Analyse de la nrme IPsec d échange de clés", WET-ICE Security Cnference, MIT,2001, [RFC1321] R. Rivest, "Algrithme de résumé de message MD5", avril (Infrmatin) [RFC1958] B. Carpenter, éd., "Principes de l'architecture de l'internet", juin (MàJ par RFC3439) (Infrmatin) [RFC2104] H. Krawczyk, M. Bellare et R. Canetti, "HMAC : Hachage de clés pur l'authentificatin de message", février [RFC2131] R. Drms, "Prtcle de cnfiguratin dynamique d'hôte", mars (Mise à jur par les RFC 3396 et 4361) [RFC2251] M. Wahl, T. Hwes et S. Kille, "Prtcle léger d accès à un répertire (v3)", décembre [RFC2367] D. McDnald, C. Metz, B. Phan, "API de gestin de clé PF_KEY, versin 2", juillet (Infrmatin) [RFC2401] S. Kent et R. Atkinsn, "Architecture de sécurité pur le prtcle Internet", nvembre (Obslète, vir

54 RFC 4306 page Kaufman & autres RFC4301) [RFC2407] D. Piper, "Le dmaine d'interprétatin de sécurité IP de l'internet pur ISAKMP", nvembre (Obslète, vir 4306) [RFC2408] D. Maughan, M. Schertler, M. Schneider et J. Turner, "Assciatin de sécurité Internet et prtcle de gestin de clés (ISAKMP)", nvembre (Obslète, vir la RFC4306) [RFC2409] D. Harkins et D. Carrel, "L'échange de clés Internet (IKE)", nvembre (Obslète, vir la RFC4306) [RFC2412] H. Orman, "Prtcle OAKLEY de déterminatin de clés", nvembre (Infrmatin) [RFC2474] K. Nichls, S. Blake, F. Baker et D. Black, "Définitin du champ Services différenciés (DS) dans les en-têtes IPv4 et IPv6", décembre (MàJ par RFC3168, RFC3260) (P.S.) [RFC2475] S. Blake, D. Black, M. Carlsn, E. Davies, Z. Wang et W. Weiss, "Architecture pur services différenciés", décembre (MàJ par RFC3260) [RFC2522] P. Karn, W. Simpsn, "Phturis : Prtcle de gestin de clé de sessin", mars (Expérimentale) [RFC2775] B. Carpenter, "Transparence de l'internet", février (Infrmatin) [RFC2865] C. Rigney et autres, "Service d'authentificatin à distance de l'utilisateur appelant (RADIUS)", juin (MàJ par RFC2868, RFC3575, RFC5080) (D.S.) [RFC2983] D. Black, "Services différenciés et tunnels", ctbre (Infrmatin) [RFC3173] A. Shacham et autres, "Prtcle de cmpressin de charge utile IP (IPCmp)", septembre (P.S.) [RFC3439] R. Bush, D. Meyer, "Lignes directrices et philsphie de l'architecture de l'internet", décembre (Infrmatin) [RFC3447] J. Jnssn et B. Kaliski, "Nrmes de cryptgraphie à clés publiques (PKCS) n 1 : Spécificatins de la cryptgraphie RSA versin 2.1", février [RFC3715] B. Abba, W. Dixn, "Exigences de cmpatibilité entre IPsec et la traductin d'adresse réseau (NAT)", mars (Inf.) [RFC4086] D. Eastlake 3 rd, J. Schiller, S. Crcker, "Exigences d'aléa pur la sécurité", juin (Remplace RFC1750) (BCP0106) [RFC4302] S. Kent, "En-tête d'authentificatin IP", décembre (P.S.) [RFC4303] S. Kent, "Encapsulatin de charge utile de sécurité dans IP (ESP)", décembre (Remplace RFC2406) (P.S.) [RSA] [SHA] [SIGMA] [SKEME] R. Rivest, A. Shamir et L. Adleman, "Méthde pur btenir des systèmes de chiffrement de signatures numériques et de clés publiques", Cmmunicatins de ACM, v. 21, n. 2, février NIST, "Nrme de hachage sécurisé", FIPS 180-1, Natinal Institute f Standards and Technlgy, U.S. Department f Cmmerce, mai H. Krawczyk, "SIGMA: the `SIGn-et-MAc' Apprach t Authenticated Diffie-Hellman and its Use in the IKE Prtcls", dans Advances in Cryptgraphy - CRYPTO 2003 Prceedings, LNCS 2729, Springer, Dispnible à : H. Krawczyk, "SKEME: A Versatile Secure Key Exchange Mechanism fr Internet", Cmpte rendu du Sympsium 1996 de l IEEE sur la sécurité des systèmes en réseau et distribués. [X.501] Recmmandatin UIT-T X.501 : Technlgies de l infrmatin - Intercnnexin des systèmes uverts L annuaire : Mdèles, [X.509] Recmmandatin UIT-T X.509 (1997 E) : Technlgies de l infrmatin - Intercnnexin des systèmes uverts L annuaire : Cadre d authentificatin, juin Appendice A : Résumé des changements depuis IKEv1 Les bjectifs de cette révisin de IKE snt : 1) de définir le prtcle IKE tut entier dans un seul dcument, remplaçant les RFC 2407, 2408, et 2409 et incrprant les changements destinés à prendre en charge la traversée de NAT, l authentificatin extensible, et l acquisitin d adresse distante ; 2) de simplifier IKE en remplaçant les huit échanges initiaux différents par un seul échange de quatre messages (avec des

55 RFC 4306 page Kaufman & autres changements dans les mécanismes d authentificatin qui affectent une seule charge utile AUTH plutôt que de restructurer tut l échange) vir [PK01] ; 3) de supprimer les champs Dmaine d interprétatin (DOI), Situatin (SIT), et Identifiant de dmaine étiqueté, et les bits Cmmit et Authenticatin nly ; 4) de diminuer la latence de IKE dans le cas curant en ramenant l échange initial à deux allers-returs (4 messages), et en permettant la capacité de prtage de l établissement de CHILD_SA sur cet échange ; 5) de remplacer la syntaxe cryptgraphique pur la prtectin des messages IKE eux-mêmes par une syntaxe fndée étritement sur ESP pur simplifier la mise en œuvre et l analyse de la sécurité ; 6) de réduire le nmbre d états d erreur pssibles en rendant le prtcle fiable (en accusant réceptin de tus les messages et en les séquençant). Cela permet de raccurcir les échanges CREATE_CHILD_SA de 3 messages à 2 ; 7) d accrître la rbustesse en permettant au répndant de ne pas faire de traitement significatif jusqu à ce qu il reçive un message pruvant que l initiateur peut recevir des messages à ce qu il prétend être sn adresse IP, et de ne pas affecter d état à un échange jusqu à ce que l initiateur puisse être cryptgraphiquement authentifié ; 8) de régler les faiblesses cryptgraphiques, cmme le prblèmes des symétries dans les hachages utilisés pur l authentificatin, dcumentées par Ter Kivinen ; 9) de spécifier les sélecteurs de trafic dans leur prpre type de charge utile plutôt que de surcharge les charges utiles d identifiant, et de rendre plus suple les sélecteurs de trafic qui peuvent être spécifiés ; 10)de spécifier le cmprtement requis sus certaines cnditins d erreur u lrs de la réceptin de dnnées nn cmprises, pur faciliter des révisins futures sans entamer la rétr cmpatibilité ; 11)de simplifier et préciser la maintenance d un état partagé en présence de défaillances de réseau et d attaques de déni de service ; et 12)de maintenir dans la mesure du pssible la syntaxe et les nmbres magiques existants pur rendre prbable la mise à niveau des mises en œuvre de IKEv1 afin qu elles puissent prendre en charge IKEv2 avec le minimum d effrts. Appendice B : Grupes Diffie-Hellman Deux grupes Diffie-Hellman snt définis ici pur usage dans IKE. Ces grupes nt été générés par Richard Schrœppel à l Université de l Arizna. Les prpriétés de ces nmbres premiers snt décrites dans la [RFC2412]. La frce apprtée par le grupe 1 peut n être pas suffisante pur l algrithme de chiffrement de mise en œuvre bligatire et ne figure ici que pur des raisns histriques. Des grupes Diffie-Hellman supplémentaires nt été définis dans [la RFC3526]. B.1 Grupe 1 MODP à 768 bits Ce grupe a reçu l id 1 (un). Le principal est : 2^768-2 ^ ^64 * { [2^638 pi] } Sa valeur hexadécimale valeur est : FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF Le générateur est 2. B.2 Grupe 2 MODP à 1024 bits Ce grupe à reçu l id 2 (deux). Le principal est 2^1024-2^ ^64 * { [2^894 pi] }. Sa valeur hexadécimale est : FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE ECE65381 FFFFFFFF FFFFFFFF Le générateur est 2.

56 RFC 4306 page Kaufman & autres Adresse de l éditeur Charlie Kaufman Micrsft Crpratin 1 Micrsft Way Redmnd, WA Phne: [email protected] Déclaratin de drits de reprductin Cpyright (C) The Internet Sciety (2006). Le présent dcument est sumis aux drits, licences et restrictins cntenus dans le BCP 78, et à et sauf pur ce qui est mentinné ci-après, les auteurs cnservent tus leurs drits. Le présent dcument et les infrmatins qui y snt cntenues snt furnies sur une base "EN L ÉTAT" et le cntributeur, l rganisatin qu il u elle représente u qui le/la finance (s il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent tutes garanties, exprimées u implicites, y cmpris mais nn limitées à tute garantie que l utilisatin des infrmatins ci enclses ne vilent aucun drit u aucune garantie implicite de cmmercialisatin u d aptitude à un bjet particulier. Prpriété intellectuelle L IETF ne prend pas psitin sur la validité et la prtée de tut drit de prpriété intellectuelle u autres drits qui purraient être revendiqués au titre de la mise en œuvre u l utilisatin de la technlgie décrite dans le présent dcument u sur la mesure dans laquelle tute licence sur de tels drits purrait être u n être pas dispnible ; pas plus qu elle ne prétend avir accmpli aucun effrt pur identifier de tels drits. Les infrmatins sur les prcédures de l ISOC au sujet des drits dans les dcuments de l ISOC figurent dans les BCP 78 et BCP 79. Des cpies des dépôts d IPR faites au secrétariat de l IETF et tutes assurances de dispnibilité de licences, u le résultat de tentatives faites pur btenir une licence u permissin générale d utilisatin de tels drits de prpriété par ceux qui mettent en œuvre u utilisent la présente spécificatin peuvent être btenues sur répertire en ligne des IPR de l IETF à L IETF invite tute partie intéressée à prter sn attentin sur tus cpyrights, licences u applicatins de licence, u autres drits de prpriété qui purraient cuvrir les technlgies qui peuvent être nécessaires pur mettre en œuvre la présente nrme. Prière d adresser les infrmatins à l IETF à [email protected]. Remerciement Le financement de la fnctin d éditin des RFC est actuellement furni par la Internet Sciety.