16. Security Considerations (セキュリティに関する考慮事項)
16.1. Attacks against the Protocol (プロトコルに対する攻撃)
16.1.1. Outside Attacks (外部攻撃)
攻撃者は、STUN操作を失敗させるために、転送中のSTUNメッセージを変更しようとする可能性があります。リクエストとレスポンスに対するこれらの攻撃は、短期または長期クレデンシャルのいずれかを使用したメッセージ完全性メカニズムを通じて検出できます。もちろん、検出されると、操作されたパケットは破棄され、STUNトランザクションは事実上失敗します。この攻撃は、パス上の攻撃者によってのみ開始できます。
転送中のSTUNメッセージを観察できるが変更できない攻撃者（たとえば、Wi-Fiなどの共有アクセスメディア上に存在する攻撃者）は、STUNリクエストを見て、すぐにSTUNレスポンス（通常はエラーレスポンス）を送信して、STUN処理を妨害することができます。MESSAGE-INTEGRITYを持つメッセージの場合、この攻撃も防止されます。ただし、一部のエラーレスポンス、特に認証に関連するエラーレスポンスは、MESSAGE-INTEGRITYで保護できません。STUN自体がTLSなどの安全なトランスポートプロトコルを介して実行される場合、これらの攻撃は完全に軽減されます。
STUN使用法によっては、これらの攻撃の影響は最小限である可能性があり、したがって、それらを阻止するためにメッセージ完全性は必要ないかもしれません。たとえば、STUNが基本STUNサーバーとともに使用され、ICEで使用するサーバー反射候補を発見する場合、認証とメッセージ完全性は必要ありません。これらの攻撃は接続性チェックフェーズ中に検出されるためです。ただし、ICE全体が適切に動作するためには、接続性チェック自体が保護される必要があります。セクション14で説明したように、STUN使用法は、認証とメッセージ完全性が必要な時期を記述します。
STUNは認証と完全性保護に共有シークレットを持つHMACを使用するため、オフライン辞書攻撃の影響を受けやすくなります。認証が使用される場合、このようなオフライン辞書攻撃の対象とならないパスワードを選択すべきです (SHOULD)。TLSを使用してチャネル自体を保護することで、これらの攻撃を軽減できます。ただし、STUNは最も一般的にUDPを介して実行され、その場合、強力なパスワードがこれらの攻撃に対する唯一の防御です。
16.1.2. Inside Attacks (内部攻撃)
悪意のあるクライアントは、大量のSTUNリクエストをサーバーに送信することによって、サーバーに対してDoS攻撃を開始しようとする可能性があります。幸いなことに、STUNリクエストはサーバーによってステートレスに処理できるため、このような攻撃を開始することは困難です。
悪意のあるクライアントは、STUNサーバーをリフレクタとして使用し、偽造されたソースIPアドレスとポートを持つリクエストを送信する可能性があります。この場合、レスポンスはそのソースIPとポートに配信されます。この攻撃にはパケット数の増幅はありません（STUNサーバーはクライアントが送信した各パケットに対して1つのパケットを送信します）が、STUNレスポンスは通常リクエストよりも大きいため、データ量のわずかな増幅があります。入口ソースアドレスフィルタリングは、この攻撃を軽減するのに役立ちます。
SOFTWARE属性を通じてエージェントの特定のソフトウェアバージョンを明らかにすると、セキュリティホールを含むことが知られているソフトウェアに対する攻撃を攻撃者がより簡単に開始できる可能性があります。実装者は、SOFTWARE属性の使用を設定可能なオプションにすべきです (SHOULD)。
16.2. Attacks Affecting the Usage (使用法に影響を与える攻撃)
このセクションでは、STUN使用法に対して開始される可能性のある攻撃をリストします。各STUN使用法は、これらの攻撃が適用可能かどうかを検討し、適用可能な場合は対策を議論しなければなりません (must)。
このセクションのほとんどの攻撃は、Bindingリクエスト/レスポンストランザクションを通じてSTUNクライアントが学習した反射アドレスを攻撃者が変更することを中心に展開します。反射アドレスの使用は使用法の機能であるため、これらの攻撃の適用可能性と救済策は使用法固有です。最も一般的なケースでは、パス上の攻撃者は反射アドレスを簡単に変更できます。たとえば、STUNがUDP上で直接実行される一般的なケースを考えてみてください。この場合、パス上の攻撃者は、BindingリクエストがSTUNサーバーに到着する前にそのソースIPアドレスを変更できます。STUNサーバーは、このIPアドレスをXOR-MAPPED-ADDRESS属性でクライアントに返し、レスポンスをその（偽造された）IPアドレスとポートに送信します。攻撃者がこのレスポンスも傍受できる場合、それをクライアントにリダイレクトできます。メッセージ完全性チェックを使用してこの攻撃から保護することは不可能です。メッセージ完全性値は、介在するNATによって変更可能でなければならないため、ソースIPアドレスをカバーできないためです。代わりに、以下にリストされている攻撃を防ぐための1つの解決策は、ICE [MMUSIC-ICE]で行われるように、クライアントが学習した反射アドレスを検証することです。他の使用法は、これらの攻撃を防ぐために他の手段を使用する場合があります。
16.2.1. Attack I: Distributed DoS (DDoS) against a Target (ターゲットに対する分散DoS攻撃)
この攻撃では、攻撃者は1つ以上のクライアントに、意図されたターゲットを指す同じ偽造された反射アドレスを提供します。これにより、STUNクライアントは、自分の反射アドレスがターゲットのアドレスと等しいと考えるようにだまされます。クライアントがトラフィックを受信するためにその反射アドレスを配布する場合（たとえば、SIPメッセージで）、トラフィックは代わりにターゲットに送信されます。この攻撃は、特にマルチメディアアプリケーションを有効にするためにSTUNを使用しているクライアントとともに使用すると、実質的な増幅を提供できます。ただし、STUNサーバーからターゲットへのパケットが攻撃者を通過するターゲットに対してのみ開始できるため、可能なケースが制限されます。
16.2.2. Attack II: Silencing a Client (クライアントをサイレントにする)
この攻撃では、攻撃者はSTUNクライアントに偽造された反射アドレスを提供します。提供される反射アドレスは、どこにもルーティングされないトランスポートアドレスです。その結果、クライアントは、反射アドレスを配布したときに受信することを期待するパケットをまったく受信しません。このエクスプロイトは、攻撃者にとってあまり興味深いものではありません。単一のクライアントに影響を与えますが、これは頻繁に望ましいターゲットではありません。さらに、攻撃を仕掛けることができる攻撃者は、他の方法でクライアントに対してより効果的なDoS攻撃を開始できます。たとえば、STUNサーバーやDHCPサーバーからクライアントが応答をまったく受信しないようにすることができます。セクション16.2.1の攻撃と同様に、この攻撃は、STUNサーバーからこの未使用のIPアドレスに向けて送信されるパケットのパス上に攻撃者がいる場合にのみ可能です。
16.2.3. Attack III: Assuming the Identity of a Client (クライアントのIDを引き受ける)
この攻撃は攻撃IIに似ています。ただし、偽造された反射アドレスは攻撃者自身を指します。これにより、攻撃者はクライアント宛のトラフィックを受信できます。
16.2.4. Attack IV: Eavesdropping (盗聴)
この攻撃では、攻撃者はクライアントに自分自身にルーティングされる反射アドレスを使用させます。次に、受信したパケットをクライアントに転送します。この攻撃により、攻撃者はクライアントに送信されるすべてのパケットを観察できます。ただし、攻撃を開始するには、攻撃者はすでにクライアントからSTUNサーバーへのパケットを観察できている必要があります。ほとんどの場合（攻撃がアクセスネットワークから開始される場合など）、これは攻撃者がすでにクライアントに送信されるパケットを観察できることを意味します。したがって、この攻撃は、クライアントからSTUNサーバーへのパス上にいるが、一般的にクライアントにルーティングされるパケットのパス上にいない攻撃者によるトラフィックの観察にのみ有用です。
16.3. Hash Agility Plan (ハッシュ敏捷性計画)
本仕様では、メッセージ完全性の計算にHMAC-SHA-1を使用しています。将来、HMAC-SHA-1が侵害されていることが判明した場合、次の修正を適用できます。
新しいハッシュを使用して計算された新しいメッセージ完全性属性を導入するSTUN拡張を定義します。クライアントは、リクエストまたはインディケーションに新旧両方のメッセージ完全性属性を含める必要があります。新しいサーバーは新しいメッセージ完全性属性を使用し、古いサーバーは古い属性を使用します。混合実装が展開される移行期間の後、古いメッセージ完全性属性は別の仕様によって非推奨となり、クライアントはリクエストにそれを含めることを停止します。
また、HMACで使用されるキー自体が、ユーザー名とパスワードのハッシュを使用して計算されることに注意することも重要です。MD5ハッシュの選択は、この形式でのパスワードのレガシーデータベース格納のために行われました。将来の作業で、MD5入力を使用したHMACの使用が安全でないことが判明し、別のハッシュが必要になった場合、この計画をその変更にも使用できます。ただし、これには管理者がデータベースを再設定する必要があります。