III.2.4. ISAKMP et le protocole Record de SSL/TLS 8
La dernière étape de notre architecture est le
chiffrement de toutes les données échangées par le
protocole Record de SSL/TLS.
Nous proposons un mécanisme simple qui ne
nécessite aucun changement au niveau du protocole Record. En
effet, ce dernier est activé lorsque les deux entités
reçoivent les messages CCS (Change Cipher Spec) durant le
dernier échange du protocole Handshake de SSL/TLS.
III.2.5. ISAKMP et TLS Extensions
Le RFC 3546 (TLS Extensions) propose une nouvelle
extension au protocole SSL/TLS vers de nouvel environnement. Ce travail a
renforcé notre proposition et a résolu tous les problèmes
de compatibilité des clients SSL/TLS qui veulent négocier ISAKMP
à la place du Handshake de SSL/TLS et des serveurs SSL/TLS qui ne
soutiennent pas cette option et vice versa.
III.2.6. Procédure pour la définition de
nouvelles extensions
La nouvelle extension que nous proposons dans ce chapitre et
dans le chapitre suivant respecte la procédure de définition de
nouvelles extensions avec TLS Extensions. Nous relevons ci-dessous certains
points qui devraient être pris en considération par ce protocole
:
v' Les extensions doivent être définies de telle
sorte que chaque extension envoyée par le client soit connue par le
serveur. Ce dernier répond avec une extension du même type. Dans
le cas oü le serveur n'accepte pas l'extension, un message d'erreur est
envoyé. En général, les messages d'erreurs ALERT de
SSL/TLS devraient être envoyés au serveur. Un champ dans
l'extension du serveur est envoyé au client ;
1' Les extensions doivent éviter toute attaque qui
force a l'utilisation (ou a la non utilisation) d'une caractéristique
particulière manipulant les messages Handshake. Ceci est vrai si les
extensions sont ajoutées au message Finished de SSL/TLS. Les
développeurs du protocole doivent être conscients que ces
extensions ne changent pas le sens des messages envoyés dans le
Handshake de SSL/TLS.
III.2.6.1. Négociation de l'échange
ISAKMP
Afin de permettre à un client TLS de négocier un
échange ISAKMP au lieu du Handshake standard de TLS, un nouveau type
d'extension devrait être ajouté aux messages
ExtendedClientHello et ExtendedServerHello.
III.2.6.2. Gestion des erreurs
Elle définit de nouveaux types d'erreurs pour l'usage
avec ISAKMP et TLS. Les deux nouvelles alertes définies sont :
unpresentjsakmp_sa et unrecognized_spi_value. Ces alertes ne
doivent être envoyées qu'à la suite de l'utilisation de TLS
Extension entre le deux communicants.
1' unsupportjsakmp_sa : cette alerte est
envoyée par le serveur si le client demande l'ouverture d'une
négociation TLS SA avant l'établissement d'une association de
sécurité ISAKMP ;
1' unrecognized_spi_value : cette alerte est
envoyée par le serveur s'il ne reconnaît pas l'identificateur de
la phase envoyé par le client.
| 
