Dato questo:
- Entrambi gli schemi di autenticazione STUN originali (cioè credenziali a breve e a lungo termine) coinvolgono il server che conosce la password in chiaro di ogni utente;
- Gli stessi schemi di autenticazione sono suscettibili all'attacco del dizionario offline, a meno che non venga utilizzato TLS / DTLS; e
- Esiste un principio generale secondo cui le password devono essere gestite con riservatezza, anche se ciò causa notevoli disagi agli implementatori e agli operatori di sistema:
Quindi è preferibile mantenere le password a lungo termine fuori dal server STUN / TURN (anche se DTLS è usato per proteggerle sul filo), per minimizzare la superficie di attacco per il database di tutte le password.
Gli schemi di autenticazione fattibili sono quindi:
- Autenticazione tramite credenziali a breve termine, consentita da RFC-5766 sezione 4 perché è almeno così strong come lo schema delle credenziali a lungo termine.
- DTLS e autenticazione con credenziali a lungo termine, in cui il server STUN effettuerà chiamate remote a un archivio di password centrale per eseguire tutte le operazioni
MESSAGE-INTEGRITY che richiedono la conoscenza delle password. L'archivio password centrale deve essere uno dei pochi sistemi soggetti a controllo e controllo della sicurezza dettagliati; avrebbe bisogno di nuove interfacce speciali per poter essere utilizzato dai server STUN.
- Protocolli generali per ottenere le credenziali di autorizzazione, ad esempio API REST per l'accesso ai servizi TURN , SAML, diametro o anche leggermente usato in modo improprio OAuth.
- DTLS e autenticazione con credenziali a lungo termine, in cui le password vengono assegnate esclusivamente per il servizio STUN e presumibilmente non correlate alle password reali degli utenti.
Di questi quattro, l'idea delle password specifiche per STUN è la più probabile causa di problemi perché ispirerà la rivolta tra gli utenti che hanno abbastanza problemi a ricordare una buona password.
L'idea di credenziali a lungo termine, con delega speciale a un server centrale, non è auspicabile perché aumenta inutilmente la superficie di attacco su quel server centrale.
Il sistema di credenziali a breve termine non è completamente specificato; le specifiche STUN / TURN non discutono sul modo in cui le credenziali vengono generate o trasportate. Dal momento che sarebbe necessario progettare un protocollo per generare tali credenziali e trasportarle sul client STUN e sul server STUN, sarebbe molto meno da ignorare lo schema di credenziali a breve termine e utilizzare invece uno dei nuovi protocolli federati. / p>
La scelta del protocollo generale non è molto importante, ma ovviamente sarebbe più semplice implementarne una che sarebbe condivisa con altri servizi. Al momento della stesura, tuttavia, L'API REST per accedere ai servizi TURN è la specifica più completa.
Pertanto, raccomando l'uso dell'API REST per ottenere nomi utente e password temporanei da un server HTTPS. Il server STUN / TURN convaliderà i nomi utente e le password utilizzando un segreto che condivide con il server HTTPS.