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.