7. Considerazioni sulla sicurezza

Questo documento specifica il protocollo di contabilità RADIUS, un'estensione di RADIUS [2]. Pertanto, i problemi di sicurezza descritti in RADIUS [2] si applicano anche alla contabilità RADIUS.

Inoltre, poiché le informazioni di contabilità sono inviate tramite UDP, che è inaffidabile, i pacchetti di contabilità possono andare persi. Per mitigare questo problema, il server di contabilità può rilevare le richieste duplicate (poiché il Request Authenticator rimane invariato nelle ritrasmissioni) e ignorarle. Tuttavia, se il server di contabilità stesso va in crash, potrebbero andare perse le registrazioni di contabilità che non sono state né memorizzate né ritrasmesse dal NAS (poiché il NAS considera completata l'operazione una volta ricevuta la risposta). Pertanto, in caso di crash del server di contabilità, alcune registrazioni potrebbero andare perse. Se la persistenza dei dati di contabilità è importante, si deve usare un trasporto affidabile come TCP invece di UDP.

I pacchetti di contabilità RADIUS non sono crittografati; chiunque possa intercettare le comunicazioni tra client e server può pertanto osservare le informazioni di contabilità. Se è richiesta la riservatezza, si deve proteggere il collegamento con IPsec o meccanismi simili.

I pacchetti di contabilità RADIUS sono autenticati tramite un segreto condiviso. Se il segreto condiviso viene compromesso, un attaccante può falsificare richieste di contabilità. Pertanto il segreto condiviso deve essere distribuito tramite un canale sicuro e deve essere abbastanza lungo da resistere ad attacchi di forza bruta.

Gli attributi di questo memo non forniscono protezione di integrità (oltre al Request/Response Authenticator). Pertanto, un intermediario potrebbe modificare gli attributi di contabilità in transito. Se questo rischio non è accettabile, si deve usare IPsec o meccanismi simili.

Se i dati di contabilità vengono inviati a terze parti non attendibili (ad esempio tramite proxy), si deve prestare attenzione affinché i dati non vengano abusati. Il proxy deve conservare i valori originali di Acct-Session-Id, Acct-Authentic e User-Name, in modo che il ricevitore possa verificarne la provenienza.

Le implementazioni devono prevenire gli attacchi di replay. Poiché il Request Authenticator è univoco e imprevedibile a ogni richiesta, dovrebbe essere difficile replicare i pacchetti di richiesta di contabilità. Tuttavia, se un attaccante può osservare e memorizzare una richiesta di contabilità valida e poi ripeterla in seguito, potrebbe causare registrazioni duplicate. Il server di contabilità può rilevare i replay mantenendo una cache dei Request Authenticator recenti.