RFC 3547 - Il Group Domain of Interpretation (The Group Domain of Interpretation)

• Stato: Proposed Standard
• Pubblicato: July 2003
• Stream: IETF
• Sostituito da: RFC6407
• Errata: Nessun errata

---

Sommario (Abstract)

Questo documento presenta un ISAKMP Domain of Interpretation (DOI) per la gestione delle chiavi di gruppo, a supporto di comunicazioni di gruppo sicure. Il GDOI gestisce le Security Association di gruppo, utilizzate da IPsec e potenzialmente da altri protocolli di data security operanti a livello IP o applicativo. Queste Security Association proteggono una o più chiavi di cifratura delle chiavi (key-encrypting keys), chiavi di cifratura del traffico (traffic-encrypting keys), o dati condivisi dai membri del gruppo.

---

Indice (Table of Contents)

• 1. Introduzione
  • 1.1. Applicazioni di GDOI
  • 1.2. Estensione di GDOI
• 2. Protocollo GDOI di Fase 1
  • 2.1. Protocollo ISAKMP di Fase 1
    • 2.1.1. Valore DOI
    • 2.1.2. Porta UDP
• 3. Scambio GROUPKEY-PULL
  • 3.1. Autorizzazione
  • 3.2. Messaggi
    • 3.2.1. Perfect Forward Secrecy
    • 3.2.2. Inizializzazione dell'header ISAKMP
  • 3.3. Operazioni dell'iniziatore
  • 3.4. Operazioni del ricevitore
• 4. Messaggio GROUPKEY-PUSH
  • 4.1. Perfect Forward Secrecy (PFS)
  • 4.2. Controllo di accesso in avanti e all'indietro
    • 4.2.1. Requisiti per il controllo di accesso in avanti
  • 4.3. Delega della gestione delle chiavi
  • 4.4. Uso delle chiavi di firma
  • 4.5. Inizializzazione dell'header ISAKMP
  • 4.6. Eliminazione delle SA
  • 4.7. Operazioni del GCKS
  • 4.8. Operazioni dei membri del gruppo
• 5. Payload e valori definiti
  • 5.1. Identification Payload
    • 5.1.1. Valori dell'Identification Type
  • 5.2. Security Association Payload
  • 5.3. SA KEK Payload
  • 5.4. SA TEK Payload
  • 5.5. Key Download Payload
  • 5.6. Sequence Number Payload
  • 5.7. Proof of Possession
  • 5.8. Nonce
• 6. Considerazioni sulla sicurezza
  • 6.1. ISAKMP Fase 1
  • 6.2. Scambio GROUPKEY-PULL
  • 6.3. Scambio GROUPKEY-PUSH
• 7. Considerazioni IANA
• 8. Dichiarazione sui diritti di proprietà intellettuale
• 9. Ringraziamenti
• 10. Riferimenti
  • 10.1. Riferimenti normativi
  • 10.2. Riferimenti informativi

Appendici (Appendices)

• Appendice A: Protocolli GDOI di Fase 1 alternativi
  • A.1. Protocollo IKEv2 di Fase 1
  • A.2. Protocollo KINK

---

Risorse correlate (Related Resources)

• Testo ufficiale: RFC 3547 (TXT)
• Pagina ufficiale: RFC 3547 DataTracker
• Errata: RFC Editor Errata

---

5.1.1. Valori dell'Identification Type (Identification Type Values)

La tabella seguente elenca i valori assegnati al campo Identification Type (tipo di identificazione) contenuto nell'Identification Payload.

Tipo di ID (ID Type)	Valore (Value)
RESERVED	0 - 10
ID_KEY_ID	11
RESERVED	12 - 127
Private Use	128 - 255

5.1.1.1. ID_KEY_ID

Nel contesto di un payload ID di GDOI, ID_KEY_ID specifica un identificatore di gruppo (group identifier) di quattro (4) ottetti.

Note sull'utilizzo

• Valore di ID_KEY_ID: 11
• Lunghezza: 4 ottetti
• Scopo: identificare in modo univoco un gruppo GDOI
• Contesto d'uso: utilizzato nello scambio GROUPKEY-PULL e nei messaggi GROUPKEY-PUSH per identificare il gruppo di destinazione

Spiegazione dei valori riservati

• 0 - 10: riservati per usi futuri
• 12 - 127: riservati per future standardizzazioni
• 128 - 255: utilizzabili per implementazioni private o estensioni sperimentali

Considerazioni sull'interoperabilità

Le implementazioni devono supportare ID_KEY_ID (valore 11) per garantire l'interoperabilità di base del protocollo GDOI. I valori di tipo ID non riconosciuti dovrebbero essere ignorati oppure gestiti secondo quanto previsto dalla specifica ISAKMP.