1.2. The Initial Exchanges

1.2 The Initial Exchanges

La communication avec IKE commence toujours par les échanges IKE_SA_INIT et IKE_AUTH (appelés Phase 1 dans IKEv1). Ces échanges initiaux comportent normalement quatre messages, bien que ce nombre puisse augmenter dans certains scénarios. Toute communication IKE consiste en paires requête/réponse. Nous décrivons d'abord l'échange de base, puis les variantes. La première paire de messages (IKE_SA_INIT) négocie les algorithmes cryptographiques, échange les nonces et effectue un échange Diffie-Hellman [DH].

La seconde paire (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 sont chiffrées et protégées en intégrité avec des clés établies par l'échange IKE_SA_INIT, de sorte que les identités sont cachées aux indiscrets et que tous les champs de tous les messages sont authentifiés. Voir la section 2.14 pour la génération des clés de chiffrement. (Un attaquant homme du milieu qui ne peut pas terminer l'échange IKE_AUTH peut néanmoins voir l'identité de l'initiator.)

Tous les messages suivant l'échange initial sont protégés cryptographiquement avec les algorithmes et clés négociés dans IKE_SA_INIT. Ces messages utilisent la syntaxe de la charge Encrypted décrite à la section 3.14, chiffrés avec des clés dérivées comme à la section 2.14. Tous les messages suivants incluent une charge Encrypted, même s'ils sont qualifiés de « vides » dans le texte. Pour les échanges CREATE_CHILD_SA, IKE_AUTH ou INFORMATIONAL, le message suivant l'en-tête est chiffré et le message incluant l'en-tête est protégé en intégrité avec les algorithmes négociés pour l'IKE SA.

Chaque message IKE contient un Message ID dans son en-tête fixe. Ce Message ID sert à associer requêtes et réponses et à identifier les retransmissions.

Dans les descriptions suivantes, les charges du message sont indiquées par les noms ci-dessous.

Notation	Payload
AUTH	Authentication
CERT	Certificate
CERTREQ	Certificate Request
CP	Configuration
D	Delete
EAP	Extensible Authentication
HDR	IKE header (not a payload)
IDi	Identification - Initiator
IDr	Identification - Responder
KE	Key Exchange
Ni, Nr	Nonce
N	Notify
SA	Security Association
SK	Encrypted and Authenticated
TSi	Traffic Selector - Initiator
TSr	Traffic Selector - Responder
V	Vendor ID

Le détail du contenu de chaque charge est décrit à la section 3. Les charges optionnelles apparaissent entre crochets, par exemple [CERTREQ], ce qui indique qu'une Certificate Request peut être incluse optionnellement.

Les échanges initiaux sont les suivants :

Initiator                         Responder
-------------------------------------------------------------------
HDR, SAi1, KEi, Ni  -->

HDR contient les Security Parameter Indexes (SPI), numéros de version, Exchange Type, Message ID et divers drapeaux. La charge SAi1 indique les algorithmes cryptographiques que l'initiator prend en charge pour l'IKE SA. La charge KE envoie la valeur Diffie-Hellman de l'initiator. Ni est le nonce de l'initiator.

                               <--  HDR, SAr1, KEr, Nr, [CERTREQ]

Le responder choisit une suite cryptographique parmi les propositions de l'initiator et l'exprime dans SAr1, termine l'échange Diffie-Hellman avec KEr et envoie son nonce dans Nr.

À ce stade de la négociation, chaque partie peut générer une quantité appelée SKEYSEED (section 2.14), d'où dérivent toutes les clés de cette IKE SA. Les messages suivants sont chiffrés et protégés en intégrité dans leur intégralité, sauf les en-têtes. Les clés de chiffrement et d'intégrité dérivent de SKEYSEED et sont nommées SK_e (chiffrement) et SK_a (authentification, c'est-à-dire protection d'intégrité) ; voir les sections 2.13 et 2.14. Un SK_e et un SK_a distincts sont calculés pour chaque sens. Outre SK_e et SK_a dérivés de la valeur Diffie-Hellman pour la protection de l'IKE SA, une quantité SK_d est dérivée pour le matériel de clé des Child SAs. La notation SK { ... } indique que ces charges sont chiffrées et protégées en intégrité avec le SK_e et SK_a de ce sens.

HDR, SK {IDi, [CERT,] [CERTREQ,]
    [IDr,] AUTH, SAi2,
    TSi, TSr}  -->

L'initiator affirme son identité avec IDi, prouve la connaissance du secret correspondant à IDi et protège en intégrité le premier message avec AUTH (section 2.15). Il peut aussi envoyer ses certificats dans CERT et ses ancres de confiance dans CERTREQ. Si des charges CERT sont incluses, le premier certificat fourni DOIT contenir la clé publique servant à vérifier le champ AUTH.

La charge optionnelle IDr permet à l'initiator de préciser avec quelle identité du responder il souhaite parler. C'est utile lorsque la machine du responder héberge plusieurs identités à la même adresse IP. Si l'IDr proposé n'est pas acceptable, le responder peut utiliser un autre IDr pour terminer. Si l'initiator n'accepte pas l'utilisation d'un IDr différent de celui demandé, il peut fermer la SA après constat.

Les Traffic Selectors (TSi et TSr) sont traités à la section 2.9.

L'initiator commence la négociation d'une Child SA avec SAi2. Les champs finaux (à partir de SAi2) sont décrits dans l'échange CREATE_CHILD_SA.

                               <--  HDR, SK {IDr, [CERT,] AUTH,
                                        SAr2, TSi, TSr}

Le responder affirme son identité avec IDr, envoie éventuellement un ou plusieurs certificats (le certificat avec la clé publique pour AUTH en premier), authentifie son identité et protège en intégrité le second message avec AUTH, et termine la négociation de la Child SA avec les champs supplémentaires décrits pour CREATE_CHILD_SA. Les deux parties de l'échange IKE_AUTH DOIVENT vérifier que toutes les signatures et Message Authentication Codes (MAC) sont correctes. Si une partie utilise un secret partagé pour l'authentification, les noms dans la charge ID DOIVENT correspondre à la clé utilisée pour générer AUTH.

Comme l'initiator envoie sa valeur Diffie-Hellman dans IKE_SA_INIT, il doit deviner le groupe Diffie-Hellman que le responder choisira dans sa liste. En cas d'erreur, le responder répond avec une charge Notify de type INVALID_KE_PAYLOAD indiquant le groupe choisi. L'initiator DOIT alors réessayer IKE_SA_INIT avec le groupe corrigé. L'initiator DOIT à nouveau proposer l'ensemble complet de ses suites acceptables car le message de rejet n'était pas authentifié ; sinon un attaquant actif pourrait forcer une suite plus faible qu'une suite plus forte préférée des deux côtés.

Si la création de la Child SA pendant IKE_AUTH échoue, l'IKE SA est tout de même créée. Les types Notify dans IKE_AUTH qui n'empêchent pas l'établissement de l'IKE SA incluent au moins : NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE et FAILED_CP_REQUIRED.

Si l'échec concerne la création de l'IKE SA (par exemple AUTHENTICATION_FAILED), l'IKE SA n'est pas créée. Bien que les messages IKE_AUTH soient chiffrés et protégés, si le pair recevant le Notify n'a pas encore authentifié l'autre extrémité (ou y échoue), l'information doit être traitée avec prudence. Plus précisément, si le MAC est correct, l'émetteur du Notify d'erreur est connu comme étant le responder de IKE_SA_INIT, mais son identité n'est pas assurée.

Les messages IKE_AUTH ne contiennent pas de charges KEi/KEr ni Ni/Nr. Ainsi les charges SA dans IKE_AUTH ne peuvent pas contenir Transform Type 4 (groupe Diffie-Hellman) avec une valeur autre que NONE. Les implémentations DEVRAIENT omettre toute la sous-structure transform plutôt que d'envoyer NONE.