21. Autenticazione dei messaggi DHCP

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

Il meccanismo di autenticazione DHCP si basa sul design dell'autenticazione per DHCPv4 [4].

21.1. Sicurezza dei messaggi inviati tra server e agenti relay

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

Gli agenti relay e i server che supportano la comunicazione sicura da agente relay a server o da agente relay a agente relay utilizzano IPsec nelle seguenti condizioni:

Selettori (Selectors): Gli agenti relay sono configurati manualmente con gli indirizzi dell'agente relay o del server a cui devono essere inoltrati i messaggi DHCP. Ogni agente relay e server che utilizzerà IPsec per proteggere i messaggi DHCP deve anche essere configurato con un elenco degli agenti relay a cui verranno restituiti i messaggi. I selettori per gli agenti relay e i server saranno le coppie di indirizzi che definiscono gli agenti relay e i server che scambiano messaggi DHCP sulle porte UDP DHCPv6 546 e 547.

Modalità (Mode): Gli agenti relay e i server utilizzano la modalità trasporto ed ESP. Le informazioni nei messaggi DHCP non sono generalmente considerate riservate, quindi la crittografia non deve essere utilizzata (cioè, può essere utilizzata la crittografia NULL).

Gestione delle chiavi (Key management): Poiché gli agenti relay e i server sono utilizzati all'interno di un'organizzazione, gli schemi a chiave pubblica non sono necessari. Poiché gli agenti relay e i server devono essere configurati manualmente, la gestione delle chiavi configurata manualmente può essere sufficiente, ma non fornisce difesa contro i messaggi riprodotti. Di conseguenza, IKE con segreti precondivisi DOVREBBE essere supportato. IKE con chiavi pubbliche PUÒ essere supportato.

Politica di sicurezza (Security policy): I messaggi DHCP tra agenti relay e server dovrebbero essere accettati solo da peer DHCP come identificati nella configurazione locale.

Autenticazione (Authentication): Le chiavi condivise, indicizzate all'indirizzo IP sorgente del messaggio DHCP ricevuto, sono adeguate in questa applicazione.

Disponibilità (Availability): Le implementazioni IPsec appropriate sono probabilmente disponibili per i server e per gli agenti relay in dispositivi più ricchi di funzionalità utilizzati nelle reti aziendali e core ISP. IPsec è meno probabile che sia disponibile per gli agenti relay in dispositivi di fascia bassa utilizzati principalmente nei mercati domestici o di piccoli uffici.

21.2. Riepilogo dell'autenticazione DHCP

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

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

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

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

21.3. Rilevamento della riproduzione

Il campo del metodo di rilevamento della riproduzione (RDM) determina il tipo di rilevamento della riproduzione utilizzato nel campo di rilevamento della riproduzione.

Se il campo RDM contiene 0x00, il campo di rilevamento della riproduzione DEVE essere impostato sul valore di un contatore monotonicamente crescente. L'utilizzo di un valore di contatore, come l'ora corrente del giorno (ad 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 differita

Se il campo protocol è 2, il messaggio sta utilizzando il meccanismo di "autenticazione differita". Nell'autenticazione differita, 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 codice di autenticazione del messaggio (MAC) per fornire l'autenticazione del messaggio e l'autenticazione dell'entità.

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

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

In un messaggio Solicit, il client riempie 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 utilizzato per costruire il contenuto del campo delle informazioni di autenticazione. Il campo RDM identifica il metodo utilizzato 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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Realm DHCP                           |
 |                      (lunghezza variabile)                    |
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                            ID chiave                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                           HMAC-MD5                            |
 |                          (128 bit)                            |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Realm DHCP (DHCP realm): Il realm DHCP che identifica la chiave utilizzata per generare il valore HMAC-MD5.

ID chiave (key ID): L'identificatore della chiave che identifica la chiave utilizzata per generare il valore HMAC-MD5.

HMAC-MD5: Il codice di autenticazione del messaggio generato applicando MD5 al messaggio DHCP utilizzando la chiave identificata dal realm DHCP, dal DUID del client e dall'ID chiave.

Il mittente calcola il MAC utilizzando l'algoritmo di generazione HMAC [8] e la funzione hash MD5 [16]. L'intero messaggio DHCP (impostando il campo MAC dell'opzione di autenticazione a zero), inclusi l'intestazione del messaggio DHCP e il campo delle opzioni, viene utilizzato come input per la 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 realm DHCP utilizzato per identificare le chiavi di autenticazione è scelto per essere unico tra i domini amministrativi. L'uso del realm DHCP consente agli amministratori DHCP di evitare conflitti nell'uso degli identificatori di chiavi e consente a un host che utilizza DHCP di utilizzare DHCP autenticato durante il roaming tra domini amministrativi DHCP.

21.4.2. Convalida del messaggio

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

Per convalidare un messaggio in arrivo, il ricevitore verifica prima che il valore nel campo di rilevamento della riproduzione sia accettabile secondo il metodo di rilevamento della riproduzione specificato dal campo RDM. Successivamente, il ricevitore calcola il MAC come descritto in [8]. L'intero messaggio DHCP (impostando il campo MAC dell'opzione di autenticazione a 0) viene utilizzato come input per la 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

Ogni client DHCP ha un insieme di chiavi. Ogni chiave è identificata da <realm DHCP, DUID client, ID chiave>. Ogni chiave ha anche una durata. La chiave non può essere utilizzata oltre la fine della sua durata. Le chiavi del client vengono inizialmente distribuite al client attraverso un meccanismo fuori banda. La durata per ogni chiave viene distribuita con la chiave. I meccanismi per la distribuzione delle chiavi e la specifica della durata sono al di fuori dell'ambito di questo documento.

Il client e il server utilizzano 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 differita

Il client annuncia la sua intenzione di utilizzare l'autenticazione DHCP includendo un'opzione Authentication nel suo messaggio Solicit. Il server seleziona una chiave per il client in base al DUID del client. Il client e il server utilizzano 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 utilizzare l'autenticazione, include un'opzione Authentication con il protocollo, l'algoritmo e il RDM desiderati come descritto nella sezione 21.4. Il client non include alcuna informazione di rilevamento della riproduzione o di autenticazione nell'opzione Authentication.

21.4.4.2. Ricezione di messaggi Advertise

Il client convalida tutti i messaggi Advertise contenenti un'opzione Authentication che specifica il protocollo di autenticazione differita utilizzando il test di convalida descritto nella sezione 21.4.2.

Il comportamento del client, se nessun messaggio Advertise include informazioni di autenticazione o supera il test di convalida, è 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 deve essere presa con attenzione. L'accettazione di un messaggio Advertise non autenticato può rendere il client vulnerabile a spoofing e altri attacchi. Se gli utenti locali non vengono esplicitamente informati che il client ha accettato un messaggio Advertise non autenticato, gli utenti potrebbero presumere erroneamente che il client abbia ricevuto un indirizzo autenticato e non sia soggetto ad attacchi DHCP attraverso messaggi non autenticati.

Un client DEVE essere configurabile per scartare i messaggi non autenticati e DOVREBBE essere configurato per impostazione predefinita per scartare i 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 superano il test di convalida; ad esempio, un client potrebbe accettare i primi e scartare i secondi. Se un client accetta un messaggio non autenticato, il client DOVREBBE informare tutti 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 il quale 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 utilizzare la stessa chiave utilizzata 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 (vedere sezione 21.4.5.1), il client DEVE utilizzare la stessa chiave per generare le informazioni di autenticazione durante tutta la sessione.

21.4.4.5. Ricezione di messaggi Reply

Se il client ha autenticato l'Advertise che ha accettato, il client DEVE convalidare il messaggio Reply associato dal server. Il client DEVE scartare il Reply se il messaggio non supera il test di convalida e PUÒ registrare il fallimento della convalida. Se il Reply non supera il test di convalida, 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 ha superato il test di convalida, 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 supera il test di convalida e PUÒ registrare il fallimento della convalida.

21.4.5. Considerazioni del server per il protocollo di autenticazione differita

Dopo aver ricevuto un messaggio Solicit che contiene un'opzione Authentication, il server seleziona una chiave per il client, in base al DUID del client e alle politiche di selezione delle chiavi con cui il server è stato configurato. Il server identifica la chiave selezionata nel messaggio Advertise e utilizza la chiave per convalidare 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 utilizzare quella stessa chiave per convalidare 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 utilizza la chiave identificata nel messaggio e convalida il messaggio come specificato nella sezione 21.4.2. Se il messaggio non supera il test di convalida 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 convalida.

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

21.5. Protocollo di autenticazione con chiave di riconfigurazione

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

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

Il protocollo della chiave di riconfigurazione viene utilizzato (avviato dal server) solo se il client e il server non stanno utilizzando nessun altro protocollo di autenticazione e il client e il server hanno negoziato l'uso dei messaggi Reconfigure.

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

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

• protocol: 3
• algorithm: 1
• RDM: 0

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

  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      |                 Valore (128 bit)              |
 +-+-+-+-+-+-+-+-+                                               |
 .                                                               .
 .                                                               .
 .                                               +-+-+-+-+-+-+-+-+
 |                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: Tipo di dati nel campo Value trasportato in questa opzione:

• 1: Valore della chiave di riconfigurazione (utilizzato nel messaggio Reply).
• 2: Digest HMAC-MD5 del messaggio (utilizzato nel messaggio Reconfigure).

Valore (Value): Dati come definiti dal campo.

21.5.2. Considerazioni del server per il protocollo della chiave di riconfigurazione

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

La chiave di riconfigurazione è 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 il RDM selezionato dal server e calcola un HMAC-MD5 del messaggio Reconfigure utilizzando la chiave di riconfigurazione 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 di riconfigurazione

Il client riceverà una chiave di riconfigurazione dal server nel messaggio Reply iniziale dal server. Il client registra la chiave di riconfigurazione da utilizzare per l'autenticazione dei successivi messaggi Reconfigure.

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