7. セキュリティに関する考慮事項

この文書は RADIUS [2] の拡張である RADIUS アカウンティングプロトコルを規定している。したがって、RADIUS [2] で説明されたセキュリティ上の問題は、RADIUS アカウンティングにも同様に当てはまる。

さらに、アカウンティング情報は信頼できない UDP を介して送信されるため、アカウンティングパケットが失われる可能性がある。これを軽減するため、アカウンティングサーバーは重複要求（再送信時に要求認証子が一定であるため）を検出して無視できる。しかし、アカウンティングサーバー自体がクラッシュした場合、保存も NAS からの再送信もされないアカウンティング記録が失われる可能性がある（NAS は応答を受信した時点で完了とみなすため）。したがって、アカウンティングサーバーのクラッシュ時にはアカウンティング記録が失われる可能性がある。アカウンティングデータの永続性が重要な場合は、UDP ではなく TCP のような信頼できる転送を使用すべきである。

RADIUS アカウンティングパケットは暗号化されない。したがって、クライアントとサーバー間の通信を傍受できる者は、アカウンティング情報を観察できる。秘匿性が必要な場合は、IPsec または類似の機構を使用してリンクを保護すべきである。

RADIUS アカウンティングパケットは、共有シークレットを用いて認証される。共有シークレットが漏洩した場合、攻撃者はアカウンティング要求を偽造できる。したがって、共有シークレットは安全なチャネルを介して配布されなければならず、ブルートフォース攻撃に耐えうる十分な長さを持つべきである。

このメモの属性は（要求/応答認証子を除いて）完全性保護を提供しない。したがって、中間者が転送中のアカウンティング属性を改ざんする可能性がある。このリスクが許容できない場合は、IPsec または類似の機構を使用すべきである。

アカウンティングデータが信頼できない第三者（プロキシ経由など）に送信される場合、データが悪用されないよう注意しなければならない。プロキシは、受信側がデータの出所を検証できるよう、Acct-Session-Id、Acct-Authentic、User-Name の元の値を保持しなければならない。

実装はリプレイ攻撃を防がなければならない。要求認証子は各要求で一意かつ予測不可能であるため、アカウンティング要求パケットのリプレイは困難であるはずである。しかし、攻撃者が有効なアカウンティング要求を観察して保存し、後でそれをリプレイした場合、重複したアカウンティング記録が生じる可能性がある。アカウンティングサーバーは、最近の要求認証子のキャッシュを維持することでリプレイを検出できる。