2.15. Authentication of the IKE SA (Authentification de l'IKE SA)

Sans authentification extensible (section 2.16), les pairs s'authentifient en signant (ou MAC avec secret partagé rembourré comme clé, voir ci-dessous) un bloc de données. IDi' et IDr' sont les charges ID entières sans l'en-tête fixe. Pour le répondant, les octets à signer commencent au premier octet du premier SPI de l'en-tête du deuxième message (réponse IKE_SA_INIT) et se terminent au dernier octet de la dernière charge. On y ajoute pour la signature le nonce Ni de l'initiateur (la valeur seule) et prf(SK_pr, IDr'). Ni ni prf(SK_pr, IDr') ne sont transmis. L'initiateur signe le premier message (requête IKE_SA_INIT) du premier SPI au dernier octet de la dernière charge, et ajoute Nr et prf(SK_pi, IDi'). Chaque côté DOIT signer le nonce de l'autre.

Octets signés par l'initiateur:

InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI
GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
RealIKEHDR =  SPIi | SPIr |  . . . | Length
RealMessage1 = RealIKEHDR | RestOfMessage1
NonceRPayload = PayloadHeader | NonceRData
InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload
RestOfInitIDPayload = IDType | RESERVED | InitIDData
MACedIDForI = prf(SK_pi, RestOfInitIDPayload)

Octets signés par le répondant:

ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR
GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
RealIKEHDR =  SPIi | SPIr |  . . . | Length
RealMessage2 = RealIKEHDR | RestOfMessage2
NonceIPayload = PayloadHeader | NonceIData
ResponderIDPayload = PayloadHeader | RestOfRespIDPayload
RestOfRespIDPayload = IDType | RESERVED | RespIDData
MACedIDForR = prf(SK_pr, RestOfRespIDPayload)

Toutes les charges sont incluses sous la signature, y compris les types non définis ici. Si le premier message est envoyé plusieurs fois (cookie, autre groupe DH), c'est la dernière version qui est signée.

En option, les messages 3 et 4 PEUVENT inclure un certificat ou une chaîne prouvant que la clé de signature numérique appartient au nom de la charge ID. La signature ou le MAC est calculé selon les algorithmes dictés par le type de clé du signataire et le champ Auth Method de la charge Authentication. Il n'est pas exigé que l'initiateur et le répondant signent avec les mêmes algorithmes cryptographiques. Le choix dépend du type de clé de chacun. En particulier, l'initiateur peut utiliser un secret partagé tandis que le répondant a une clé de signature publique et un certificat. Il est fréquent (mais non requis) qu'avec un secret partagé pour l'authentification, la même clé serve dans les deux sens.

Noter qu'il est courant mais typiquement peu sûr de n'avoir qu'un secret partagé dérivé uniquement d'un mot de passe choisi par l'utilisateur sans autre source d'aléa. C'est typiquement peu sûr car les mots de passe choisis ont peu de chances d'avoir assez d'imprévisibilité pour résister aux attaques par dictionnaire, et ces attaques ne sont pas empêchées par cette méthode d'authentification. (Les applications utilisant l'authentification par mot de passe pour amorcer l'IKE SA devraient utiliser la méthode de la section 2.16, conçue pour empêcher les attaques par dictionnaire hors ligne.) Le secret pré-partagé doit contenir autant d'imprévisibilité que la clé la plus forte négociée. Avec secret pré-partagé, la valeur AUTH est calculée comme suit:

Pour l'initiateur:

AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"),
                 <InitiatorSignedOctets>)

Pour le répondant:

AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"),
                 <ResponderSignedOctets>)

La chaîne "Key Pad for IKEv2" comporte 17 caractères ASCII sans terminaison nulle. Le secret partagé peut être de longueur variable. La chaîne de remplissage permet, si le secret est dérivé d'un mot de passe, que l'implémentation IKE n'ait pas à stocker le mot de passe en clair mais puisse stocker prf(Shared Secret,"Key Pad for IKEv2"), inutilisable comme équivalent de mot de passe pour d'autres protocoles qu'IKEv2. Comme indiqué, dériver le secret d'un mot de passe seul n'est pas sûr. Cette construction est utilisée car l'on anticipe que des personnes le feront quand même. L'interface de gestion par laquelle le secret est fourni DOIT accepter des chaînes ASCII d'au moins 64 octets et NE DOIT PAS ajouter de terminateur nul avant usage comme secret. Elle DOIT aussi accepter un encodage hexadécimal du secret. Elle PEUT accepter d'autres encodages si l'algorithme de traduction vers une chaîne binaire est spécifié.

Il existe deux types d'authentification EAP (section 2.16), et chaque type utilise des valeurs différentes dans les calculs AUTH ci-dessus. Si la méthode EAP génère une clé, substituer la master session key (MSK) au secret partagé. Pour les méthodes sans génération de clé, substituer respectivement SK_pi et SK_pr au secret partagé dans les deux calculs AUTH.

2.15. Authentication of the IKE SA (Authentification de l'IKE SA)​

2.15. Authentication of the IKE SA (Authentification de l'IKE SA)