21. Autenticazione dei messaggi DHCP

21. Autenticazione dei messaggi DHCP

Alcuni amministratori di rete possono desiderare di fornire l'autenticazione della fonte e del contenuto dei messaggi DHCP. Per esempio, i client possono essere soggetti ad attacchi di denial of service attraverso l'uso di server DHCP fasulli, o possono semplicemente essere configurati in modo errato a causa di server DHCP istantiati involontariamente. Gli amministratori di rete possono desiderare di vincolare l'allocazione di indirizzi a host autorizzati per evitare attacchi di denial of service in ambienti "ostili" dove il mezzo di rete non è fisicamente sicuro, come reti wireless o residenze universitarie.

Il meccanismo di autenticazione DHCP è basato sul design dell'autenticazione per DHCPv4 [4].

21.1. Sicurezza dei messaggi scambiati tra server e agenti di relay

Gli agenti di relay e i server che scambiano messaggi in modo sicuro usano i meccanismi IPsec per IPv6 [7]. Se un messaggio client è inoltrato attraverso più agenti di relay, ciascuno degli agenti di relay deve aver stabilito relazioni di fiducia indipendenti e a coppie. Cioè, se i messaggi dal client C saranno inoltrati dall'agente di relay A all'agente di relay B e poi al server, gli agenti di relay A e B devono essere configurati per usare IPSec per i messaggi che scambiano, e l'agente di relay B e il server devono essere configurati per usare IPSec per i messaggi che scambiano.

Gli agenti di relay e i server che supportano la comunicazione sicura agente di relay-server o agente di relay-agente di relay usano IPsec nelle seguenti condizioni:

Aspetto	Descrizione
Selectors	Gli agenti di relay sono configurati manualmente con gli indirizzi dell'agente di relay o del server a cui inoltrare i messaggi DHCP. Ciascun agente di relay e server che userà IPsec per proteggere i messaggi DHCP deve anche essere configurato con un elenco degli agenti di relay a cui i messaggi saranno restituiti. I selector per gli agenti di relay e i server saranno le coppie di indirizzi che definiscono agenti di relay e server che scambiano messaggi DHCP sulle porte UDP DHCPv6 546 e 547.
Mode	Gli agenti di relay e i server usano la transport mode e ESP. Le informazioni nei messaggi DHCP non sono generalmente considerate riservate, quindi la crittografia non deve essere usata (cioè, può essere usata la crittografia NULL).
Key management	Poiché gli agenti di relay e i server sono usati all'interno di un'organizzazione, schemi a chiave pubblica non sono necessari. Poiché gli agenti di relay e i server devono essere configurati manualmente, la gestione delle chiavi configurata manualmente può essere sufficiente, ma non fornisce difesa contro messaggi riprodotti. Di conseguenza, IKE con segreti pre-condivisi DOVREBBE essere supportato. IKE con chiavi pubbliche PUÒ essere supportato.
Security policy	I messaggi DHCP tra agenti di relay e server dovrebbero essere accettati solo da peer DHCP come identificato nella configurazione locale.
Authentication	Chiavi condivise, indicizzate all'indirizzo IP sorgente del messaggio DHCP ricevuto, sono adeguate in questa applicazione.
Availability	Implementazioni IPsec appropriate saranno probabilmente disponibili per i server e per gli agenti di relay in dispositivi più ricchi usati in reti aziendali e core ISP. IPsec è meno probabile sia disponibile per agenti di relay in dispositivi di fascia bassa usati principalmente nei mercati domestico o delle piccole imprese.

21.2. Riassunto dell'autenticazione DHCP

L'autenticazione dei messaggi DHCP è realizzata attraverso l'uso dell'opzione Authentication (si veda la sezione 22.11). Le informazioni di autenticazione trasportate nell'opzione Authentication possono essere usate per identificare in modo affidabile la fonte di un messaggio DHCP e per confermare che il contenuto del messaggio DHCP non è stato alterato.

L'opzione Authentication fornisce un quadro per più protocolli di autenticazione. Due di tali protocolli sono definiti qui. Altri protocolli definiti in futuro saranno specificati in documenti separati.

Ciascun messaggio DHCP NON DEVE includere più di un'opzione Authentication.

Il campo protocol nell'opzione Authentication identifica il protocollo specifico usato per generare le informazioni di autenticazione trasportate nell'opzione. Il campo algorithm identifica un algoritmo specifico all'interno del protocollo di autenticazione; per esempio, il campo algorithm specifica l'algoritmo di hash usato per generare il message authentication code (MAC) nell'opzione di autenticazione. Il campo del metodo di rilevamento della riproduzione (RDM) specifica il tipo di rilevamento della riproduzione usato nel campo di rilevamento della riproduzione.

21.3. Rilevamento della riproduzione

Il campo Replay Detection Method (RDM) determina il tipo di rilevamento della riproduzione usato nel campo Replay Detection.

Se il campo RDM contiene 0x00, il campo di rilevamento della riproduzione DEVE essere impostato al valore di un contatore a incremento monotono. L'uso di un valore di contatore, come l'ora corrente del giorno (per esempio, un timestamp in formato NTP [9]), può ridurre il pericolo di attacchi di riproduzione. Questo metodo DEVE essere supportato da tutti i protocolli.

21.4. Protocollo di autenticazione ritardata (Delayed Authentication)

Se il campo protocol è 2, il messaggio usa il meccanismo di "autenticazione ritardata". Nell'autenticazione ritardata, il client richiede l'autenticazione nel suo messaggio Solicit, e il server risponde con un messaggio Advertise che include informazioni di autenticazione. Queste informazioni di autenticazione contengono un valore nonce generato dalla fonte come message authentication code (MAC) per fornire autenticazione del messaggio e autenticazione dell'entità.

L'uso di una particolare tecnica basata sul protocollo HMAC [8] usando l'hash MD5 [16] è definito qui.

21.4.1. Uso dell'opzione Authentication nel protocollo di autenticazione ritardata

In un messaggio Solicit, il client compila i campi protocol, algorithm e RDM nell'opzione Authentication con le preferenze del client. Il client imposta il campo di rilevamento della riproduzione a zero e omette il campo delle informazioni di autenticazione. Il client imposta il campo option-len a 11.

In tutti gli altri messaggi, i campi protocol e algorithm identificano il metodo usato per costruire il contenuto del campo delle informazioni di autenticazione. Il campo RDM identifica il metodo usato per costruire il contenuto del campo di rilevamento della riproduzione.

Il formato delle informazioni di autenticazione è:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          DHCP realm                           |
|                      (variable length)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            key ID                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                           HMAC-MD5                            |
|                          (128 bits)                           |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• DHCP realm — Il DHCP realm che identifica la chiave usata per generare il valore HMAC-MD5.
• key ID — L'identificatore di chiave che ha identificato la chiave usata per generare il valore HMAC-MD5.
• HMAC-MD5 — Il message authentication code generato applicando MD5 al messaggio DHCP usando la chiave identificata dal DHCP realm, dal DUID del client e dal key ID.

Il mittente calcola il MAC usando l'algoritmo di generazione HMAC [8] e la funzione di hash MD5 [16]. L'intero messaggio DHCP (impostando il campo MAC dell'opzione di autenticazione a zero), inclusa l'intestazione del messaggio DHCP e il campo delle opzioni, è usato come input alla funzione di calcolo HMAC-MD5.

DISCUSSIONE:

L'Algoritmo 1 specifica l'uso di HMAC-MD5. L'uso di una tecnica diversa, come HMAC-SHA, sarà specificato come protocollo separato.

Il DHCP realm usato per identificare le chiavi di autenticazione è scelto per essere unico tra domini amministrativi. L'uso del DHCP realm consente agli amministratori DHCP di evitare conflitti nell'uso degli identificatori di chiave, e consente a un host che usa DHCP di usare DHCP autenticato mentre vaga tra domini amministrativi DHCP.

21.4.2. Validazione dei messaggi

Ciascun messaggio DHCP che include più di un'opzione di autenticazione DEVE essere scartato.

Per validare un messaggio in arrivo, il ricevitore verifica per prima cosa che il valore nel campo di rilevamento della riproduzione sia accettabile secondo il metodo di rilevamento della riproduzione specificato dal campo RDM. Quindi, il ricevitore calcola il MAC come descritto in [8]. L'intero messaggio DHCP (impostando il campo MAC dell'opzione di autenticazione a 0) è usato come input alla funzione di calcolo HMAC-MD5. Se il MAC calcolato dal ricevitore non corrisponde al MAC contenuto nell'opzione di autenticazione, il ricevitore DEVE scartare il messaggio DHCP.

21.4.3. Utilizzo delle chiavi

Ciascun client DHCP ha un insieme di chiavi. Ciascuna chiave è identificata da <DHCP realm, DUID client, key id>. Ciascuna chiave ha anche un tempo di vita. La chiave non può essere usata oltre la fine del suo tempo di vita. Le chiavi del client sono inizialmente distribuite al client attraverso qualche meccanismo out-of-band. Il tempo di vita per ciascuna chiave è distribuito con la chiave. I meccanismi per la distribuzione delle chiavi e la specifica del tempo di vita sono al di fuori dello scopo di questo documento.

Il client e il server usano una delle chiavi del client per autenticare i messaggi DHCP durante una sessione (fino al successivo messaggio Solicit inviato dal client).

21.4.4. Considerazioni del client per il protocollo di autenticazione ritardata

Il client annuncia la sua intenzione di usare l'autenticazione DHCP includendo un'opzione Authentication nel suo messaggio Solicit. Il server seleziona una chiave per il client basandosi sul DUID del client. Il client e il server usano quella chiave per autenticare tutti i messaggi DHCP scambiati durante la sessione.

21.4.4.1. Invio di messaggi Solicit

Quando il client invia un messaggio Solicit e desidera usare l'autenticazione, include un'opzione Authentication con il protocol, algorithm e RDM desiderati come descritto nella sezione 21.4. Il client non include alcun rilevamento della riproduzione o informazioni di autenticazione nell'opzione Authentication.

21.4.4.2. Ricezione di messaggi Advertise

Il client valida tutti i messaggi Advertise contenenti un'opzione Authentication che specifica il protocollo di autenticazione ritardata usando il test di validazione descritto nella sezione 21.4.2.

Il comportamento del client, se nessun messaggio Advertise include informazioni di autenticazione o passa il test di validazione, è controllato dalla politica locale sul client. Secondo la politica del client, il client PUÒ scegliere di rispondere a un messaggio Advertise che non è stato autenticato.

La decisione di impostare la politica locale per accettare messaggi non autenticati dovrebbe essere presa con cautela. Accettare un messaggio Advertise non autenticato può rendere il client vulnerabile a spoofing e altri attacchi. Se gli utenti locali non sono esplicitamente informati che il client ha accettato un messaggio Advertise non autenticato, gli utenti possono erroneamente presumere che il client abbia ricevuto un indirizzo autenticato e non sia soggetto ad attacchi DHCP tramite messaggi non autenticati.

Un client DEVE essere configurabile per scartare messaggi non autenticati, e DOVREBBE essere configurato per impostazione predefinita per scartare messaggi non autenticati se il client è stato configurato con una chiave di autenticazione o altre informazioni di autenticazione. Un client PUÒ scegliere di differenziare tra messaggi Advertise senza informazioni di autenticazione e messaggi Advertise che non passano il test di validazione; per esempio, un client potrebbe accettare i primi e scartare i secondi. Se un client accetta un messaggio non autenticato, il client DOVREBBE informare gli utenti locali e DOVREBBE registrare l'evento.

21.4.4.3. Invio di messaggi Request, Confirm, Renew, Rebind, Decline o Release

Se il client ha autenticato il messaggio Advertise attraverso cui il client ha selezionato il server, il client DEVE generare informazioni di autenticazione per i successivi messaggi Request, Confirm, Renew, Rebind o Release inviati al server, come descritto nella sezione 21.4. Quando il client invia un messaggio successivo, DEVE usare la stessa chiave usata dal server per generare le informazioni di autenticazione.

21.4.4.4. Invio di messaggi Information-request

Se il server ha selezionato una chiave per il client in uno scambio di messaggi precedente (si veda la sezione 21.4.5.1), il client DEVE usare la stessa chiave per generare le informazioni di autenticazione per tutta la sessione.

21.4.4.5. Ricezione di messaggi Reply

Se il client ha autenticato il messaggio Advertise che ha accettato, il client DEVE validare il messaggio Reply associato dal server. Il client DEVE scartare il Reply se il messaggio non passa il test di validazione e PUÒ registrare il fallimento della validazione. Se il Reply non passa il test di validazione, il client DEVE riavviare il processo di configurazione DHCP inviando un messaggio Solicit.

Se il client ha accettato un messaggio Advertise che non includeva informazioni di autenticazione o non passava il test di validazione, il client PUÒ accettare un messaggio Reply non autenticato dal server.

21.4.4.6. Ricezione di messaggi Reconfigure

Il client DEVE scartare il Reconfigure se il messaggio non passa il test di validazione e PUÒ registrare il fallimento della validazione.

21.4.5. Considerazioni del server per il protocollo di autenticazione ritardata

Dopo aver ricevuto un messaggio Solicit che contiene un'opzione Authentication, il server seleziona una chiave per il client, basandosi sul DUID del client e sulle politiche di selezione della chiave con cui il server è stato configurato. Il server identifica la chiave selezionata nel messaggio Advertise e usa la chiave per validare i messaggi successivi tra il client e il server.

21.4.5.1. Ricezione di messaggi Solicit e invio di messaggi Advertise

Il server seleziona una chiave per il client e include informazioni di autenticazione nel messaggio Advertise restituito al client come specificato nella sezione 21.4. Il server DEVE registrare l'identificatore della chiave selezionata per il client e usare quella stessa chiave per validare i messaggi successivi con il client.

21.4.5.2. Ricezione di messaggi Request, Confirm, Renew, Rebind o Release e invio di messaggi Reply

Il server usa la chiave identificata nel messaggio e valida il messaggio come specificato nella sezione 21.4.2. Se il messaggio non passa il test di validazione o il server non conosce la chiave identificata dal campo 'key ID', il server DEVE scartare il messaggio e PUÒ scegliere di registrare il fallimento della validazione.

Se il messaggio passa il test di validazione, il server risponde al messaggio specifico come descritto nella sezione 18.2. Il server DEVE includere informazioni di autenticazione generate usando la chiave identificata nel messaggio ricevuto, come specificato nella sezione 21.4.

21.5. Protocollo di autenticazione con chiave Reconfigure

Il protocollo di autenticazione con chiave Reconfigure fornisce protezione contro la configurazione errata di un client causata da un messaggio Reconfigure inviato da un server DHCP malintenzionato. In questo protocollo, un server DHCP invia una Reconfigure Key al client nello scambio iniziale di messaggi DHCP. Il client registra la Reconfigure Key per usarla nell'autenticare successivi messaggi Reconfigure da quel server. Il server include quindi un HMAC calcolato dalla Reconfigure Key nei successivi messaggi Reconfigure.

Sia la Reconfigure Key inviata dal server al client che l'HMAC nei successivi messaggi Reconfigure sono trasportate come informazioni di autenticazione in un'opzione Authentication. Il formato delle informazioni di autenticazione è definito nella seguente sezione.

Il protocollo della chiave Reconfigure è usato (avviato dal server) solo se il client e il server non stanno usando alcun altro protocollo di autenticazione e il client e il server hanno negoziato di usare messaggi Reconfigure.

21.5.1. Uso dell'opzione Authentication nel protocollo di autenticazione con chiave Reconfigure

I seguenti campi sono impostati in un'opzione Authentication per il protocollo di autenticazione con chiave Reconfigure:

• protocol — 3
• algorithm — 1
• RDM — 0

Il formato delle informazioni di autenticazione per il protocollo di autenticazione con chiave Reconfigure è:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |                 Value (128 bits)              |
+-+-+-+-+-+-+-+-+-+                                               |
.                                                               .
.                                                               .
.                                               +-+-+-+-+-+-+-+-+
|                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• Type — Tipo di dati nel campo Value trasportato in questa opzione:
  • 1 — Valore della Reconfigure Key (usato nel messaggio Reply).
  • 2 — Digest HMAC-MD5 del messaggio (usato nel messaggio Reconfigure).
• Value — Dati come definiti dal campo.

21.5.2. Considerazioni del server per il protocollo della chiave Reconfigure

Il server seleziona una Reconfigure Key per un client durante lo scambio di messaggi Request/Reply, Solicit/Reply o Information-request/Reply. Il server registra la Reconfigure Key e la trasmette al client in un'opzione Authentication nel messaggio Reply.

La Reconfigure Key è lunga 128 bit, e DEVE essere un numero casuale o pseudo-casuale crittograficamente forte che non può essere facilmente previsto.

Per fornire l'autenticazione per un messaggio Reconfigure, il server seleziona un valore di rilevamento della riproduzione secondo l'RDM selezionato dal server, e calcola un HMAC-MD5 del messaggio Reconfigure usando la Reconfigure Key per il client. Il server calcola l'HMAC-MD5 sull'intero messaggio DHCP Reconfigure, inclusa l'opzione Authentication; il campo HMAC-MD5 nell'opzione Authentication è impostato a zero per il calcolo HMAC-MD5. Il server include l'HMAC-MD5 nel campo delle informazioni di autenticazione in un'opzione Authentication inclusa nel messaggio Reconfigure inviato al client.

21.5.3. Considerazioni del client per il protocollo della chiave Reconfigure

Il client riceverà una Reconfigure Key dal server nel messaggio Reply iniziale dal server. Il client registra la Reconfigure Key per usarla nell'autenticare successivi messaggi Reconfigure.

Per autenticare un messaggio Reconfigure, il client calcola un HMAC-MD5 sul messaggio DHCP Reconfigure, usando la Reconfigure Key ricevuta dal server. Se questo HMAC-MD5 calcolato corrisponde al valore nell'opzione Authentication, il client accetta il messaggio Reconfigure.