RFC 3547 - Le domaine d'interprétation de groupe (The Group Domain of Interpretation)

• Statut: Proposed Standard
• Publié: July 2003
• Stream: IETF
• Remplacé par: RFC6407
• Errata: Pas d'errata

---

Résumé (Abstract)

Ce document présente un domaine d'interprétation ISAKMP (ISAKMP Domain of Interpretation, DOI) pour la gestion des clés de groupe afin de prendre en charge les communications de groupe sécurisées. Le GDOI (Group Domain of Interpretation) gère les associations de sécurité de groupe (Security Associations), qui sont utilisées par IPsec et potentiellement d'autres protocoles de sécurité des données fonctionnant aux couches IP ou application. Ces associations de sécurité protègent une ou plusieurs clés de chiffrement de clés (Key-Encrypting Keys), clés de chiffrement de trafic (Traffic-Encrypting Keys), ou données partagées par les membres du groupe.

---

Table des matières (Table of Contents)

• 1. Introduction
  • 1.1. Applications GDOI
  • 1.2. Extension du GDOI
• 2. Protocole GDOI Phase 1
  • 2.1. Protocole ISAKMP Phase 1
    • 2.1.1. Valeur DOI
    • 2.1.2. Port UDP
• 3. Échange GROUPKEY-PULL
  • 3.1. Autorisation
  • 3.2. Messages
    • 3.2.1. Confidentialité persistante parfaite
    • 3.2.2. Initialisation de l'en-tête ISAKMP
  • 3.3. Opérations de l'initiateur
  • 3.4. Opérations du récepteur
• 4. Message GROUPKEY-PUSH
  • 4.1. Confidentialité persistante parfaite (PFS)
  • 4.2. Contrôle d'accès avant et arrière
    • 4.2.1. Exigences de contrôle d'accès avant
  • 4.3. Délégation de la gestion des clés
  • 4.4. Utilisation des clés de signature
  • 4.5. Initialisation de l'en-tête ISAKMP
  • 4.6. Suppression des SA
  • 4.7. Opérations GCKS
  • 4.8. Opérations des membres du groupe
• 5. Charges utiles et valeurs définies
  • 5.1. Charge utile d'identification
    • 5.1.1. Valeurs de type d'identification
  • 5.2. Charge utile d'association de sécurité
  • 5.3. Charge utile SA KEK
  • 5.4. Charge utile SA TEK
  • 5.5. Charge utile de téléchargement de clés
  • 5.6. Charge utile de numéro de séquence
  • 5.7. Preuve de possession
  • 5.8. Nonce
• 6. Considérations de sécurité
  • 6.1. ISAKMP Phase 1
  • 6.2. Échange GROUPKEY-PULL
  • 6.3. Échange GROUPKEY-PUSH
• 7. Considérations IANA
• 8. Déclaration sur les droits de propriété intellectuelle
• 9. Remerciements
• 10. Références
  • 10.1. Références normatives
  • 10.2. Références informatives

Annexes (Appendices)

• Annexe A : Protocoles GDOI Phase 1 alternatifs
  • A.1. Protocole IKEv2 Phase 1
  • A.2. Protocole KINK

---

Ressources connexes (Related Resources)

• Texte officiel : RFC 3547 (TXT)
• Page officielle : RFC 3547 DataTracker
• Errata : RFC Editor Errata

---

5.1.1. Valeurs du type d'identification (Identification Type Values)

Le tableau suivant énumère les valeurs attribuées au champ Identification Type (type d'identification) présent dans la charge utile d'identification (Identification Payload).

Type d'ID (ID Type)	Valeur (Value)
RESERVED	0 - 10
ID_KEY_ID	11
RESERVED	12 - 127
Private Use	128 - 255

5.1.1.1. ID_KEY_ID

Dans le contexte d'une charge utile ID de GDOI, ID_KEY_ID spécifie un identifiant de groupe (group identifier) de quatre (4) octets.

Notes d'utilisation

• Valeur d'ID_KEY_ID : 11
• Longueur : 4 octets
• Rôle : identifier de manière unique un groupe GDOI
• Cas d'usage : utilisé dans l'échange GROUPKEY-PULL et dans les messages GROUPKEY-PUSH afin d'identifier le groupe cible

Explication des valeurs réservées

• 0 - 10 : réservées pour un usage futur
• 12 - 127 : réservées pour une normalisation future
• 128 - 255 : utilisables pour des implémentations privées ou des extensions expérimentales

Considérations d'interopérabilité

Les implémentations doivent prendre en charge ID_KEY_ID (valeur 11) afin de garantir l'interopérabilité de base du protocole GDOI. Les valeurs de type d'ID non reconnues devraient être ignorées ou traitées conformément à la spécification ISAKMP.