8. Key Management Considerations (Considérations sur la gestion des clés)
8. Key Management Considerations (Considérations sur la gestion des clés)
Il existe des normes émergentes de gestion des clés [MIKEY] [KEYMGT] [SDMS] pour établir un contexte cryptographique SRTP (par exemple, une clé maître SRTP). Des méthodes de gestion des clés propriétaires et basées sur des normes ouvertes sont susceptibles d'être utilisées pour les applications de téléphonie [MIKEY] [KINK] et les applications multicast [GDOI]. Cette section fournit des orientations pour les systèmes de gestion des clés qui desservent une session SRTP.
Pour l'initialisation, une implémentation SRTP interopérable DEVRAIT recevoir le SSRC et PEUT recevoir le numéro de séquence RTP initial pour le flux RTP par la gestion des clés (ainsi, la gestion des clés dépend des paramètres opérationnels RTP). L'envoi du numéro de séquence RTP dans la gestion des clés peut être utile, par exemple, lorsque le numéro de séquence initial est proche du bouclage (pour éviter les problèmes de synchronisation), et pour communiquer le numéro de séquence actuel à un point de terminaison rejoignant (pour initialiser correctement sa liste de rejeu).
Si les transformations prédéfinies sont utilisées, SRTP permet le partage de la même clé maître entre les flux SRTP/SRTCP appartenant à la même session RTP.
Premièrement, le partage entre les flux SRTP appartenant à la même session RTP est sécurisé si la conception du mécanisme de synchronisation, c'est-à-dire l'IV, évite la réutilisation du flux de clés (le two-time pad, Section 9.1). Ceci est pris en charge par le fait que RTP fournit des SSRC uniques pour les flux appartenant à la même session RTP. Voir la Section 9.1 pour plus de détails.
Deuxièmement, le partage entre SRTP et le SRTCP correspondant est sécurisé. Le fait qu'un flux SRTP et son flux SRTCP associé portent tous deux le même SSRC ne constitue pas un problème pour le two-time pad en raison de la dérivation de clé. Ainsi, SRTP et SRTCP correspondant à une session RTP PEUVENT partager des clés maîtres (comme ils le font par défaut).
Notez que l'authentification des messages a également une dépendance à l'unicité du SSRC qui n'est pas liée au problème de réutilisation du flux de clés: les flux SRTP authentifiés sous la même clé DOIVENT avoir un SSRC distinct afin d'identifier l'expéditeur du message. Cette exigence est nécessaire car le SSRC est le champ authentifié cryptographiquement utilisé pour distinguer les différents flux SRTP. Si deux flux utilisaient des valeurs SSRC identiques, un adversaire pourrait substituer des messages d'un flux à l'autre sans détection.
SRTP/SRTCP NE DOIT PAS partager de clés maîtres dans d'autres circonstances que celles données ci-dessus, c'est-à-dire entre SRTP et son SRTCP correspondant, et entre les flux appartenant à la même session RTP.