11.3. Re-keying and access control
11.3. Re-keying and access control
Le renouvellement des clés peut se produire en raison du contrôle d'accès (par exemple, lorsqu'un membre est supprimé pendant une session RTP multidiffusion), ou pour des raisons purement cryptographiques (par exemple, la clé est à la fin de sa durée de vie). Lors de l'utilisation des transformations par défaut SRTP, la clé maîtresse DOIT être remplacée avant que l'un des espaces d'index ne soit épuisé pour l'un des flux protégés par une seule et même clé maîtresse.
La manière dont la gestion des clés renouvelle les implémentations SRTP est hors de portée, mais il est clair qu'il existe des moyens simples de gérer les clés pour un groupe multidiffusion. Dans la multidiffusion à un émetteur, par exemple, il incombe généralement à l'émetteur de déterminer quand une nouvelle clé est nécessaire. L'émetteur est la seule entité qui peut suivre quand le nombre maximum de paquets a été envoyé, car les récepteurs peuvent rejoindre et quitter la session à tout moment, il peut y avoir une perte de paquets et un délai, etc. Dans des scénarios autres que la multidiffusion à un émetteur, d'autres méthodes peuvent être utilisées. Ici, il faut prendre en considération que l'échange de clés peut être une opération coûteuse, prenant plusieurs secondes pour un seul échange. Par conséquent, un certain temps avant que la clé maîtresse ne soit épuisée/expire, la gestion des clés hors bande est initiée, résultant en une nouvelle clé maîtresse qui est partagée avec le(s) récepteur(s). Dans tous les cas, pour maintenir la synchronisation lors du passage à la nouvelle clé, la politique du groupe peut choisir entre l'utilisation du MKI et du <From, To>, comme décrit dans la section 8.1.
À des fins de contrôle d'accès, les périodes <From, To> sont définies à la granularité souhaitée, en fonction du débit de paquets. Un renouvellement des clés à haut débit peut être problématique pour SRTCP dans certains scénarios de grands groupes. Comme mentionné, il existe des problèmes potentiels dans l'utilisation de l'index SRTP, plutôt que de l'index SRTCP, pour déterminer la clé maîtresse. En particulier, pendant de courtes périodes lors du changement de clés maîtresses, il peut arriver que les paquets SRTCP ne soient pas sous la clé maîtresse actuelle du SRTP correspondant. Par conséquent, l'utilisation du MKI pour le renouvellement des clés dans de tels scénarios produira de meilleurs résultats.