10. Authentication and Message-Integrity Mechanisms (Meccanismi di autenticazione e integrità dei messaggi)

Questa sezione definisce due meccanismi che i client e i server possono utilizzare per fornire autenticazione e integrità dei messaggi in STUN; questi due meccanismi sono noti come meccanismo di credenziali a breve termine (short-term credential mechanism) e meccanismo di credenziali a lungo termine (long-term credential mechanism). Questi due meccanismi sono opzionali e ogni utilizzo deve (must) specificare se e quando questi meccanismi vengono utilizzati. Pertanto, sia i client che i server sapranno quale meccanismo (se presente) seguire in base alla conoscenza di quale utilizzo si applica. Ad esempio, un server STUN su Internet pubblico che supporta ICE non avrebbe autenticazione, mentre la funzionalità del server STUN in un agente che supporta i controlli di connettività utilizzerebbe il meccanismo di credenziali a breve termine. Una panoramica di questi due meccanismi è fornita nella Sezione 3.

Ogni meccanismo specifica l'elaborazione aggiuntiva richiesta per utilizzare quel meccanismo, estendendo l'elaborazione specificata nella Sezione 7. L'elaborazione aggiuntiva si verifica in tre luoghi diversi: durante la formazione di un messaggio, durante la ricezione di un messaggio immediatamente dopo l'esecuzione dei controlli di base e nell'elaborazione dettagliata delle risposte di errore.

10.1. Short-Term Credential Mechanism (Meccanismo di credenziali a breve termine)

Il meccanismo di credenziali a breve termine presuppone che, prima della transazione STUN, il client e il server abbiano utilizzato un altro protocollo per scambiare una credenziale sotto forma di nome utente e password. Questa credenziale è limitata nel tempo. Il limite di tempo è definito dall'utilizzo.

Ad esempio, nell'utilizzo ICE [MMUSIC-ICE], i due endpoint utilizzano la segnalazione fuori banda per concordare un nome utente e una password, e questo nome utente e password sono applicabili per la durata della sessione multimediale.

Questa credenziale viene utilizzata per formare un controllo di integrità del messaggio in ogni richiesta e in molte risposte. Non c'è challenge e risposta come nel meccanismo a lungo termine; di conseguenza, il replay è prevenuto in virtù della natura temporalmente limitata della credenziale.

10.1.1. Forming a Request or Indication (Formazione di una richiesta o indicazione)

Per un messaggio di richiesta o indicazione, l'agente deve (MUST) includere gli attributi USERNAME e MESSAGE-INTEGRITY nel messaggio. L'HMAC per l'attributo MESSAGE-INTEGRITY viene calcolato come descritto nella Sezione 15.4. Si noti che la password non è mai inclusa nella richiesta o nell'indicazione.

10.1.2. Receiving a Request or Indication (Ricezione di una richiesta o indicazione)

Dopo che l'agente ha eseguito l'elaborazione di base di un messaggio, l'agente esegue i controlli elencati di seguito nell'ordine specificato:

• Se il messaggio non contiene sia un attributo MESSAGE-INTEGRITY che un attributo USERNAME:

  • Se il messaggio è una richiesta, il server deve (MUST) rifiutare la richiesta con una risposta di errore. Questa risposta deve (MUST) utilizzare un codice di errore di 400 (Bad Request).

  • Se il messaggio è un'indicazione, l'agente deve (MUST) scartare silenziosamente l'indicazione.

• Se l'USERNAME non contiene un valore di nome utente attualmente valido all'interno del server:

  • Se il messaggio è una richiesta, il server deve (MUST) rifiutare la richiesta con una risposta di errore. Questa risposta deve (MUST) utilizzare un codice di errore di 401 (Unauthorized).

  • Se il messaggio è un'indicazione, l'agente deve (MUST) scartare silenziosamente l'indicazione.

• Utilizzando la password associata al nome utente, calcolare il valore per l'integrità del messaggio come descritto nella Sezione 15.4. Se il valore risultante non corrisponde al contenuto dell'attributo MESSAGE-INTEGRITY:

  • Se il messaggio è una richiesta, il server deve (MUST) rifiutare la richiesta con una risposta di errore. Questa risposta deve (MUST) utilizzare un codice di errore di 401 (Unauthorized).

  • Se il messaggio è un'indicazione, l'agente deve (MUST) scartare silenziosamente l'indicazione.

Se questi controlli hanno successo, l'agente continua a elaborare la richiesta o l'indicazione. Qualsiasi risposta generata dal server deve (MUST) includere l'attributo MESSAGE-INTEGRITY, calcolato utilizzando la password utilizzata per autenticare la richiesta. La risposta non deve (MUST NOT) contenere l'attributo USERNAME.

Se uno dei controlli fallisce, un server non deve (MUST NOT) includere un attributo MESSAGE-INTEGRITY o USERNAME nella risposta di errore. Questo perché, in questi casi di fallimento, il server non può determinare il segreto condiviso necessario per calcolare MESSAGE-INTEGRITY.

10.1.3. Receiving a Response (Ricezione di una risposta)

Il client cerca l'attributo MESSAGE-INTEGRITY nella risposta. Se presente, il client calcola l'integrità del messaggio sulla risposta come definito nella Sezione 15.4, utilizzando la stessa password che ha utilizzato per la richiesta. Se il valore risultante corrisponde al contenuto dell'attributo MESSAGE-INTEGRITY, la risposta è considerata autenticata. Se il valore non corrisponde, o se MESSAGE-INTEGRITY non era presente, la risposta deve (MUST) essere scartata, come se non fosse mai stata ricevuta. Ciò significa che le ritrasmissioni, se applicabili, continueranno.

10.2. Long-Term Credential Mechanism (Meccanismo di credenziali a lungo termine)

Il meccanismo di credenziali a lungo termine si basa su una credenziale a lungo termine, sotto forma di nome utente e password condivisi tra client e server. La credenziale è considerata a lungo termine poiché si presume che sia fornita per un utente e rimanga valida fino a quando l'utente non è più un abbonato del sistema o fino a quando non viene modificata. Questo è fondamentalmente il tradizionale nome utente e password di "accesso" dati agli utenti.

Poiché si prevede che questi nomi utente e password siano validi per periodi prolungati, la prevenzione del replay viene fornita sotto forma di challenge digest. In questo meccanismo, il client invia inizialmente una richiesta, senza offrire credenziali o controlli di integrità. Il server rifiuta questa richiesta, fornendo all'utente un realm (utilizzato per guidare l'utente o l'agente nella selezione di un nome utente e password) e un nonce. Il nonce fornisce protezione dal replay. È un cookie, selezionato dal server, e codificato in modo da indicare un periodo di validità o un'identità del client da cui è valido. Il client riprova la richiesta, questa volta includendo il suo nome utente e realm, ed echeggiando il nonce fornito dal server. Il client include anche un'integrità del messaggio, che fornisce un HMAC sull'intera richiesta, incluso il nonce. Il server valida il nonce e controlla l'integrità del messaggio. Se corrispondono, la richiesta è autenticata. Se il nonce non è più valido, è considerato "obsoleto" e il server rifiuta la richiesta, fornendo un nuovo nonce.

Nelle richieste successive allo stesso server, il client riutilizza il nonce, il nome utente, il realm e la password che ha utilizzato in precedenza. In questo modo, le richieste successive non vengono rifiutate fino a quando il server non invalida il nonce, nel qual caso il rifiuto fornisce al client un nuovo nonce.

Si noti che il meccanismo di credenziali a lungo termine non può essere utilizzato per proteggere le indicazioni, poiché le indicazioni non possono essere sfidate. Gli utilizzi che utilizzano indicazioni devono utilizzare il meccanismo di credenziali a breve termine o omettere l'autenticazione e l'integrità dei messaggi per esse.

Poiché il meccanismo di credenziali a lungo termine è suscettibile ad attacchi di dizionario offline, le distribuzioni dovrebbero (SHOULD) utilizzare password difficili da indovinare. Nei casi in cui la credenziale non viene inserita da un utente ma viene piuttosto collocata su un dispositivo client durante il provisioning del dispositivo, la password dovrebbe (SHOULD) avere almeno 128 bit di casualità. Nei casi in cui la credenziale viene inserita da un utente, dovrebbero (SHOULD) seguire le attuali best practice sulla struttura delle password.

10.2.1. Forming a Request (Formazione di una richiesta)

Ci sono due casi durante la formazione di una richiesta. Nel primo caso, questa è la prima richiesta dal client al server (identificato dal suo indirizzo IP e porta). Nel secondo caso, il client sta inviando una richiesta successiva dopo il completamento riuscito di una precedente transazione richiesta/risposta. La formazione di richieste come conseguenza di una risposta di errore 401 o 438 è trattata nella Sezione 10.2.3 e non è considerata una "richiesta successiva", e quindi non utilizza le regole descritte nella Sezione 10.2.1.2.

10.2.1.1. First Request (Prima richiesta)

Se il client non ha completato una transazione richiesta/risposta riuscita con il server (identificato dal nome host, se vengono utilizzate le procedure DNS della Sezione 9, o dall'indirizzo IP se non viene utilizzato), dovrebbe (SHOULD) omettere gli attributi USERNAME, MESSAGE-INTEGRITY, REALM e NONCE. In altre parole, la primissima richiesta viene inviata come se non fosse applicata alcuna autenticazione o integrità del messaggio.

10.2.1.2. Subsequent Requests (Richieste successive)

Una volta completata con successo una transazione richiesta/risposta, il server avrà fornito al client un realm e un nonce, e il client avrà selezionato un nome utente e una password con cui si è autenticato. Il client dovrebbe (SHOULD) memorizzare nella cache il nome utente, la password, il realm e il nonce per le comunicazioni successive con il server. Quando il client invia una richiesta successiva, dovrebbe (SHOULD) includere gli attributi USERNAME, REALM e NONCE con questi valori memorizzati nella cache. Dovrebbe (SHOULD) includere l'attributo MESSAGE-INTEGRITY, calcolato come descritto nella Sezione 15.4 utilizzando la password memorizzata nella cache.

10.2.2. Receiving a Request (Ricezione di una richiesta)

Dopo che il server ha eseguito l'elaborazione di base di una richiesta, esegue i controlli elencati di seguito nell'ordine specificato:

• Se il messaggio non contiene un attributo MESSAGE-INTEGRITY, il server deve (MUST) generare una risposta di errore con un codice di errore di 401 (Unauthorized). Questa risposta deve (MUST) includere un valore REALM. È raccomandato (RECOMMENDED) che il valore REALM sia il nome di dominio del fornitore del server STUN. La risposta deve (MUST) includere un NONCE, selezionato dal server. La risposta non dovrebbe (SHOULD NOT) includere un attributo USERNAME o MESSAGE-INTEGRITY.

• Se il messaggio contiene un attributo MESSAGE-INTEGRITY, ma manca l'attributo USERNAME, REALM o NONCE, il server deve (MUST) generare una risposta di errore con un codice di errore di 400 (Bad Request). Questa risposta non dovrebbe (SHOULD NOT) includere un attributo USERNAME, NONCE, REALM o MESSAGE-INTEGRITY.

• Se il NONCE non è più valido, il server deve (MUST) generare una risposta di errore con un codice di errore di 438 (Stale Nonce). Questa risposta deve (MUST) includere gli attributi NONCE e REALM e non dovrebbe (SHOULD NOT) includere l'attributo USERNAME o MESSAGE-INTEGRITY. I server possono invalidare i nonce per fornire sicurezza aggiuntiva. Vedere la Sezione 4.3 di [RFC2617] per le linee guida.

• Se il nome utente nell'attributo USERNAME non è valido, il server deve (MUST) generare una risposta di errore con un codice di errore di 401 (Unauthorized). Questa risposta deve (MUST) includere un valore REALM. È raccomandato (RECOMMENDED) che il valore REALM sia il nome di dominio del fornitore del server STUN. La risposta deve (MUST) includere un NONCE, selezionato dal server. La risposta non dovrebbe (SHOULD NOT) includere un attributo USERNAME o MESSAGE-INTEGRITY.

• Utilizzando la password associata al nome utente nell'attributo USERNAME, calcolare il valore per l'integrità del messaggio come descritto nella Sezione 15.4. Se il valore risultante non corrisponde al contenuto dell'attributo MESSAGE-INTEGRITY, il server deve (MUST) rifiutare la richiesta con una risposta di errore. Questa risposta deve (MUST) utilizzare un codice di errore di 401 (Unauthorized). Deve (MUST) includere gli attributi REALM e NONCE e non dovrebbe (SHOULD NOT) includere l'attributo USERNAME o MESSAGE-INTEGRITY.

Se questi controlli hanno successo, il server continua a elaborare la richiesta. Qualsiasi risposta generata dal server (eccetto i casi sopra) deve (MUST) includere l'attributo MESSAGE-INTEGRITY, calcolato utilizzando il nome utente e la password utilizzati per autenticare la richiesta. Gli attributi REALM, NONCE e USERNAME non dovrebbero (SHOULD NOT) essere inclusi.

10.2.3. Receiving a Response (Ricezione di una risposta)

Se la risposta è una risposta di errore con un codice di errore di 401 (Unauthorized), il client dovrebbe (SHOULD) riprovare la richiesta con una nuova transazione. Questa richiesta deve (MUST) contenere un USERNAME, determinato dal client come il nome utente appropriato per il REALM dalla risposta di errore. La richiesta deve (MUST) contenere il REALM, copiato dalla risposta di errore. La richiesta deve (MUST) contenere il NONCE, copiato dalla risposta di errore. La richiesta deve (MUST) contenere l'attributo MESSAGE-INTEGRITY, calcolato utilizzando la password associata al nome utente nell'attributo USERNAME. Il client non deve (MUST NOT) eseguire questo tentativo se non sta modificando l'USERNAME o il REALM o la password associata rispetto al tentativo precedente.

Se la risposta è una risposta di errore con un codice di errore di 438 (Stale Nonce), il client deve (MUST) riprovare la richiesta, utilizzando il nuovo NONCE fornito nella risposta 438 (Stale Nonce). Questo tentativo deve (MUST) anche includere USERNAME, REALM e MESSAGE-INTEGRITY.

Il client cerca l'attributo MESSAGE-INTEGRITY nella risposta (successo o fallimento). Se presente, il client calcola l'integrità del messaggio sulla risposta come definito nella Sezione 15.4, utilizzando la stessa password che ha utilizzato per la richiesta. Se il valore risultante corrisponde al contenuto dell'attributo MESSAGE-INTEGRITY, la risposta è considerata autenticata. Se il valore non corrisponde, o se MESSAGE-INTEGRITY non era presente, la risposta deve (MUST) essere scartata, come se non fosse mai stata ricevuta. Ciò significa che le ritrasmissioni, se applicabili, continueranno.