Passa al contenuto principale

20. Autenticazione dei messaggi DHCP

Questa sezione conserva il testo della RFC su DHCPv6, inclusi scambi di messaggi, comportamento dei relay, DUID, IA_NA, IA_TA, IA_PD, opzioni DHCP, autenticazione RKAP, registri IANA, requisiti normativi e matrici in appendice sull'apparizione delle opzioni.

Testo originale della RFC​

20.  Autenticazione dei messaggi DHCP

   Questo documento definisce due meccanismi di sicurezza per
   l'autenticazione dei messaggi DHCP: (1) autenticazione (e cifratura) dei
   messaggi inviati tra server e relay agent usando IPsec e (2) protezione
   contro la configurazione errata di un client causata da un messaggio
   Reconfigure inviato da un server DHCP malevolo.

20.1.  Sicurezza dei messaggi inviati tra server e relay agent

   I relay agent e i server che scambiano messaggi possono usare IPsec
   come dettagliato in [RFC8213].

20.2.  Riepilogo dell'autenticazione DHCP

   L'autenticazione dei messaggi DHCP e realizzata tramite l'uso
   dell'opzione Authentication (vedere Section 21.11).  Le informazioni di
   autenticazione trasportate nell'opzione Authentication possono essere
   usate per identificare in modo affidabile la sorgente di un messaggio
   DHCP e per confermare che i contenuti del messaggio DHCP non siano
   stati manomessi.

   L'opzione Authentication fornisce un framework per piu protocolli di
   autenticazione.  Uno di tali protocolli, RKAP, e definito nella
   Section 20.4.  Altri protocolli definiti in futuro saranno specificati
   in documenti separati.

   Qualsiasi messaggio DHCP MUST NOT includere piu di una 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 uno specifico
   algoritmo all'interno del protocollo di autenticazione; ad esempio, il
   campo algorithm specifica l'algoritmo di hash usato per generare il
   Message Authentication Code (MAC) nell'opzione Authentication.  Il
   campo RDM specifica il tipo di replay detection usato nel campo replay
   detection.

20.3.  Rilevamento dei replay

   Il campo RDM dell'opzione Authentication (vedere Section 21.11)
   determina il tipo di replay detection usato nel campo replay detection.

   Se il campo RDM contiene 0x00, il campo replay detection MUST essere
   impostato al valore di un intero senza segno a 64 bit strettamente
   monotonicamente crescente (modulo 2^64).  L'uso di questa tecnica puo
   ridurre il pericolo di attacchi replay.  Questo metodo MUST essere
   supportato da tutti i protocolli dell'opzione Authentication.  Una
   scelta potrebbe essere usare il formato timestamp NTP a 64 bit
   [RFC5905]).

   Un client che riceve un messaggio con il campo RDM impostato a 0x00
   MUST confrontare il suo campo replay detection con il valore precedente
   inviato dallo stesso server (in base all'opzione Server Identifier;
   vedere Section 21.3) e accettare il messaggio solo se il valore
   ricevuto e maggiore, registrandolo come nuovo valore.  Se questa e la
   prima volta che un client elabora un'opzione Authentication inviata da
   un server, il client MUST registrare il valore replay detection e
   saltare il controllo di replay detection.

   I server che supportano il meccanismo reconfigure MUST garantire che il
   valore replay detection sia conservato tra i riavvii.  Non farlo puo
   indurre i client a rifiutare messaggi Reconfigure inviati dal server,
   rendendo di fatto inutile il meccanismo reconfigure.

20.4.  Reconfiguration Key Authentication Protocol (RKAP)

   RKAP fornisce protezione contro la configurazione errata di un client
   causata da un messaggio Reconfigure inviato da un server DHCP malevolo.
   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'autenticazione dei successivi messaggi
   Reconfigure provenienti da quel server.  Il server quindi include nei
   successivi messaggi Reconfigure un Hashed Message Authentication Code
   (HMAC) calcolato dalla reconfigure key.

   Sia la reconfigure key inviata dal server al client sia l'HMAC nei
   successivi messaggi Reconfigure sono trasportati come informazioni di
   autenticazione in un'opzione Authentication (vedere Section 21.11).  Il
   formato delle informazioni di autenticazione e definito nella sezione
   seguente.

   RKAP e usato (iniziato dal server) solo se client e server hanno
   negoziato l'uso dei messaggi Reconfigure.

20.4.1.  Uso dell'opzione Authentication in RKAP

   I seguenti campi sono impostati in un'opzione Authentication (vedere
   Section 21.11) per RKAP:

   *  protocol: 3

   *  algorithm: 1

   *  RDM: 0

   The format of the authentication information for RKAP is:

    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)              |
   +-+-+-+-+-+-+-+-+                                               |
   .                                                               .
   .                                                               .
   .                                               +-+-+-+-+-+-+-+-+
   |                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figura 11: Informazioni di autenticazione RKAP

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

      1  Valore di reconfigure key (usato nel messaggio Reply).

      2  Digest HMAC-MD5 del messaggio (usato nel messaggio
         Reconfigure).

      Un campo di 1 ottetto.

   Value:  Dati come definiti dal campo Type.  Un campo di 16 ottetti.

20.4.2.  Considerazioni sul server per RKAP

   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
   trasmette tale chiave al client in un'opzione Authentication (vedere
   Section 21.11) nel messaggio Reply.

   La reconfigure key e lunga 128 bit e MUST essere un numero casuale o
   pseudocasuale crittograficamente forte che non possa essere facilmente
   previsto.

   Per fornire autenticazione per un messaggio Reconfigure, il server
   seleziona un valore replay detection 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 e
   impostato a 0 per il calcolo HMAC-MD5.  Il server include l'HMAC-MD5
   nel campo authentication information in un'opzione Authentication
   inclusa nel messaggio Reconfigure inviato al client.

20.4.3.  Considerazioni sul client per RKAP

   Il client ricevera una reconfigure key dal server in un'opzione
   Authentication (vedere Section 21.11) nel messaggio Reply iniziale dal
   server.  Il client registra la reconfigure key per usarla
   nell'autenticazione dei successivi messaggi Reconfigure.

   Per autenticare un messaggio Reconfigure, il client calcola un HMAC-MD5
   sul messaggio Reconfigure, con zeri sostituiti al campo HMAC-MD5,
   usando la reconfigure key ricevuta dal server.  Se questo HMAC-MD5
   calcolato corrisponde al valore nell'opzione Authentication, il client
   accetta il messaggio Reconfigure.