Passa al contenuto principale

1.5. Extending Kerberos without Breaking Interoperability (Estendere Kerberos senza Compromettere l'Interoperabilità)

Overview (Panoramica)​

Man mano che la base installata di implementazioni Kerberos cresce, estendere Kerberos diventa più importante. Questa sezione fornisce linee guida per consentire alle implementazioni future di mantenere l'interoperabilità.

Extension Mechanism (Meccanismo di Estensione)​

Kerberos fornisce un meccanismo generale per l'estensibilità del protocollo:

  • I messaggi di protocollo contengono buchi tipizzati (typed holes)
  • I sotto-messaggi contengono una stringa di ottetti con un intero che definisce l'interpretazione
  • I tipi interi sono registrati centralmente
  • Possono essere utilizzati per estensioni del fornitore e standardizzazioni IETF

Definizione: In questo documento, "estensione" si riferisce alla definizione di un nuovo tipo da inserire in un buco tipizzato esistente, non all'aggiunta di nuovi campi ai tipi ASN.1 (a meno che non sia esplicitamente indicato).

1.5.1. Compatibility with RFC 1510 (Compatibilità con RFC 1510)​

Limitations (Limitazioni)​

I formati di messaggio Kerberos esistenti non possono essere facilmente estesi aggiungendo campi ai tipi ASN.1:

  • L'invio di campi aggiuntivi spesso risulta nell'intero messaggio che viene scartato
  • Nessuna indicazione di errore fornita

Requirements for Implementations (Requisiti per le Implementazioni)​

Tutte le implementazioni nuove o modificate che ricevono un'estensione di messaggio sconosciuta:

  • DOVREBBERO: Preservare la codifica dell'estensione
  • DOVREBBERO: Ignorare la sua presenza
  • NON DEVONO: Rifiutare una richiesta semplicemente perché è presente un'estensione

Exception: Authorization Data (Eccezione: Dati di Autorizzazione)​

Se un tipo di elemento di dati di autorizzazione sconosciuto viene ricevuto da un server (diverso dal servizio di concessione ticket):

  • Sia in un AP-REQ
  • O in un ticket contenuto in un AP-REQ
  • Allora l'autenticazione DEVE fallire

Motivazione: I dati di autorizzazione limitano l'uso del ticket. Se il servizio non può determinare se la restrizione si applica, può risultare una debolezza di sicurezza.

Best Practice (Migliore Pratica): Gli elementi di autorizzazione opzionali DOVREBBERO essere racchiusi in un elemento AD-IF-RELEVANT.

Ticket-Granting Service Behavior (Comportamento del Servizio di Concessione Ticket)​

Il TGS:

  • DEVE ignorare ma propagare ai ticket derivati qualsiasi tipo di dati di autorizzazione sconosciuto
  • Eccezione: Se i tipi di dati sono incorporati in un elemento MANDATORY-FOR-KDC, la richiesta verrà rifiutata

1.5.2. Sending Extensible Messages (Invio di Messaggi Estensibili)​

Core Principle (Principio Fondamentale)​

È necessario prestare attenzione per garantire che le vecchie implementazioni possano comprendere i messaggi loro inviati, anche se non comprendono un'estensione utilizzata.

Regola: A meno che il mittente non sappia che un'estensione è supportata, l'estensione non può cambiare la semantica del messaggio principale o delle estensioni precedentemente definite.

Example Scenario (Scenario di Esempio)​

Un'estensione che include informazioni chiave necessarie per decrittografare la parte crittografata di KDC-REP:

  • Può essere utilizzata solo quando si sa che il destinatario supporta l'estensione
  • Il client potrebbe indicare il supporto tramite un elemento padata nella sequenza AS-REQ
  • Il KDC dovrebbe utilizzare l'estensione solo se l'elemento padata è presente

Best Practice (Migliore Pratica): Se la policy richiede l'estensione, restituire un errore che indica che l'estensione è richiesta piuttosto che utilizzarla quando il destinatario potrebbe non supportarla. Questo rende il debug più facile.

Reference (Riferimento)​

Per i dettagli tecnici completi, fare riferimento all'originale RFC 4120 Sezione 1.5.

Ultimo aggiornamento il