III.2.3.2. Négociation de TLS SA
Après l'établissement de la première
association de sécurité, les deux entités commencent
à négocier les paramètres de sécurité de
SSL/TLS.
Dans cette deuxième phase, l'initiateur (le client
SSL/TLS) indique dans l'en-tête ISAKMP, «TLS Quick Mode>
comme type d'échange. Il spécifie un identificateur du message
(message_ID) non nul, ajoute les deux cookies de la phase 1 et met le
champ « flag » à 1 pour indiquer que les messages sont
chiffrés. Le premier message comprend aussi :
1' Un Bloc HASH qui suit l'en-tête ISAKMP. Ce bloc
contient le résultat de hachage pour toute ou une partie de ce message
ISAKMP ;
1' Un bloc SA, précisant « TLS10
» comme protocole de sécurité utilisé dans cette
phase ;
1' Un bloc Proposal qui se rapporte au protocole TLS10
auquel est associé un
SPI (Security Parameter Index) choisi
aléatoirement par l'initiateur ;
1' Un ou plusieurs blocs Transform pour le bloc
Proposal. Ceux-ci définissent
les différents attributs proposés par l'initiateur
;
V' Un bloc NONCE (NONCEi, NONCEr) qui sert à
transporter de nouveaux aléas ;
V' Un bloc Key Exchange (KE) qui sert
à transporter les données nécessaires à la
génération d'une nouvelle clé DH partagée. Ce bloc
contient aussi le champ group qui indique le nombre premier
utilisé pour la génération des clés. Ce champ prend
par défaut la valeur « Modular Exponentiation » avec
768 bits pour le nombre premier et 2 pour le générateur DH ;
1' Deux blocs d'identification (IDi, IDr). Le premier
sert (IDi) à identifier le client. Il contient l'adresse
0.0.0.0/0. Le deuxième (IDr) sert à identifier un
serveur parmi le rang d'adresse envoyé dans le même bloc
(IDr) pendant la première phase. Le mécanisme que nous
proposons ici permet aux clients de préciser depuis leur premier
message, le serveur auquel ils souhaitent accéder ;
V' Un bloc de demande de certificat (Certificate
Request).
L'emploi des blocs KE, HASH, ID et CERTReq
est optionnel. Le bloc KE est utilisé si les deux
communicateurs veulent assurer la propriété de PFS (Perfect
Forward Secrecy) dans la génération des secrets
partagés. Comme expliqué dans le RFC 2409, la présence du
bloc HASH après les blocs SAs est explicite dans
chaque message. Par contre dans notre échange, ce bloc est optionnel si
les deux communicateurs utilisent un mécanisme d'authentification forte
tel que la signature RSA (RSA_SIG).
III.2.3.2. Générations des clés
(phase 1 et 2)
En utilisant une fonction perf (clé,
message), les deux entités vont générer un ensemble
de clés pour le chiffrement des messages ISAKMP et la dérivation
de nouvelles clés. L'intégration d'ISAKMP dans SSL/TLS
nécessite un mécanisme de génération des
clés qui respecte le mécanisme de dérivation des
clés produit par le protocole Handshake de SSL/TLS, défini dans
le RFC 2246. Ceci, afin d'obtenir les mêmes paramètres de
sécurité utilisés par le protocole Record de SSL/TLS.
| 
