メインコンテンツまでスキップ

10. Authentication and Message-Integrity Mechanisms (認証とメッセージ完全性メカニズム)

本セクションでは、クライアントとサーバーがSTUNで認証とメッセージ完全性を提供するために使用できる2つのメカニズムを定義します。これら2つのメカニズムは、短期クレデンシャルメカニズム (short-term credential mechanism) と長期クレデンシャルメカニズム (long-term credential mechanism) として知られています。これら2つのメカニズムはオプションであり、各使用法では、これらのメカニズムを使用するかどうか、またいつ使用するかを指定しなければなりません (must)。したがって、クライアントとサーバーの両方は、どの使用法が適用されるかの知識に基づいて、どのメカニズム（もしあれば）に従うかを知ることになります。たとえば、ICEをサポートするパブリックインターネット上のSTUNサーバーには認証がありませんが、接続性チェックをサポートするエージェント内のSTUNサーバー機能は短期クレデンシャルメカニズムを使用します。これら2つのメカニズムの概要は、セクション3で提供されています。

各メカニズムは、そのメカニズムを使用するために必要な追加処理を指定し、セクション7で指定された処理を拡張します。追加処理は、メッセージを形成するとき、基本チェックが実行された直後にメッセージを受信するとき、およびエラー応答の詳細な処理の3つの異なる場所で発生します。

10.1. Short-Term Credential Mechanism (短期クレデンシャルメカニズム)​

短期クレデンシャルメカニズムは、STUNトランザクションの前に、クライアントとサーバーが他のプロトコルを使用してユーザー名とパスワードの形式のクレデンシャルを交換していることを前提としています。このクレデンシャルには時間制限があります。時間制限は使用法によって定義されます。

たとえば、ICE使用法 [MMUSIC-ICE] では、2つのエンドポイントがアウトオブバンドシグナリングを使用してユーザー名とパスワードに合意し、このユーザー名とパスワードはメディアセッションの期間中適用されます。

このクレデンシャルは、各リクエストと多くの応答でメッセージ完全性チェックを形成するために使用されます。長期メカニズムのようなチャレンジとレスポンスはありません。したがって、リプレイはクレデンシャルの時間制限の性質によって防止されます。

10.1.1. Forming a Request or Indication (リクエストまたはインディケーションの形成)​

リクエストまたはインディケーションメッセージの場合、エージェントはメッセージにUSERNAME属性とMESSAGE-INTEGRITY属性を含めなければなりません (MUST)。MESSAGE-INTEGRITY属性のHMACは、セクション15.4で説明されているように計算されます。パスワードはリクエストまたはインディケーションに含まれないことに注意してください。

10.1.2. Receiving a Request or Indication (リクエストまたはインディケーションの受信)​

エージェントがメッセージの基本処理を完了した後、エージェントは以下にリストされているチェックを指定された順序で実行します:

  • メッセージにMESSAGE-INTEGRITY属性とUSERNAME属性の両方が含まれていない場合:

    • メッセージがリクエストの場合、サーバーはエラー応答でリクエストを拒否しなければなりません (MUST)。この応答は、エラーコード400 (Bad Request) を使用しなければなりません (MUST)。

    • メッセージがインディケーションの場合、エージェントはインディケーションを静かに破棄しなければなりません (MUST)。

  • USERNAMEにサーバー内で現在有効なユーザー名値が含まれていない場合:

    • メッセージがリクエストの場合、サーバーはエラー応答でリクエストを拒否しなければなりません (MUST)。この応答は、エラーコード401 (Unauthorized) を使用しなければなりません (MUST)。

    • メッセージがインディケーションの場合、エージェントはインディケーションを静かに破棄しなければなりません (MUST)。

  • ユーザー名に関連付けられたパスワードを使用して、セクション15.4で説明されているようにメッセージ完全性の値を計算します。結果の値がMESSAGE-INTEGRITY属性の内容と一致しない場合:

    • メッセージがリクエストの場合、サーバーはエラー応答でリクエストを拒否しなければなりません (MUST)。この応答は、エラーコード401 (Unauthorized) を使用しなければなりません (MUST)。

    • メッセージがインディケーションの場合、エージェントはインディケーションを静かに破棄しなければなりません (MUST)。

これらのチェックが通過すると、エージェントはリクエストまたはインディケーションの処理を続行します。サーバーによって生成される応答には、リクエストの認証に使用されたパスワードを使用して計算されたMESSAGE-INTEGRITY属性を含めなければなりません (MUST)。応答にはUSERNAME属性を含めてはなりません (MUST NOT)。

いずれかのチェックが失敗した場合、サーバーはエラー応答にMESSAGE-INTEGRITY属性またはUSERNAME属性を含めてはなりません (MUST NOT)。これは、これらの失敗ケースでは、サーバーがMESSAGE-INTEGRITYを計算するために必要な共有シークレットを決定できないためです。

10.1.3. Receiving a Response (レスポンスの受信)​

クライアントは応答内のMESSAGE-INTEGRITY属性を探します。存在する場合、クライアントは、リクエストに使用したのと同じパスワードを使用して、セクション15.4で定義されているように応答のメッセージ完全性を計算します。結果の値がMESSAGE-INTEGRITY属性の内容と一致する場合、応答は認証されたと見なされます。値が一致しない場合、またはMESSAGE-INTEGRITYが存在しない場合、応答は、まるで受信されなかったかのように破棄されなければなりません (MUST)。これは、該当する場合、再送信が継続されることを意味します。

10.2. Long-Term Credential Mechanism (長期クレデンシャルメカニズム)​

長期クレデンシャルメカニズムは、クライアントとサーバー間で共有されるユーザー名とパスワードの形式の長期クレデンシャルに依存します。クレデンシャルは長期と見なされます。これは、ユーザーのためにプロビジョニングされ、ユーザーがシステムのサブスクライバーでなくなるか、変更されるまで有効であると想定されるためです。これは基本的に、ユーザーに与えられる従来の「ログイン」ユーザー名とパスワードです。

これらのユーザー名とパスワードは長期間有効であることが予想されるため、リプレイ防止はダイジェストチャレンジの形で提供されます。このメカニズムでは、クライアントは最初に、クレデンシャルや完全性チェックを提供せずにリクエストを送信します。サーバーはこのリクエストを拒否し、ユーザーにレルム (realm、ユーザーまたはエージェントがユーザー名とパスワードを選択する際のガイドとして使用される) とナンス (nonce) を提供します。ナンスはリプレイ保護を提供します。これはサーバーによって選択されたクッキーであり、有効期間またはそれが有効なクライアントIDを示すようにエンコードされています。クライアントはリクエストを再試行し、今度はユーザー名とレルムを含め、サーバーが提供したナンスをエコーバックします。クライアントはまた、ナンスを含むリクエスト全体にHMACを提供するメッセージ完全性も含めます。サーバーはナンスを検証し、メッセージ完全性をチェックします。一致すれば、リクエストは認証されます。ナンスが有効でなくなった場合、それは「古い (stale)」と見なされ、サーバーはリクエストを拒否し、新しいナンスを提供します。

同じサーバーへの後続のリクエストでは、クライアントは以前使用したナンス、ユーザー名、レルム、パスワードを再利用します。このようにして、サーバーがナンスを無効にするまで、後続のリクエストは拒否されません。その時点で、拒否によってクライアントに新しいナンスが提供されます。

長期クレデンシャルメカニズムはインディケーションを保護するために使用できないことに注意してください。これは、インディケーションにチャレンジできないためです。インディケーションを使用する使用法は、短期クレデンシャルメカニズムを使用するか、それらの認証とメッセージ完全性を省略する必要があります。

長期クレデンシャルメカニズムはオフライン辞書攻撃の影響を受けやすいため、展開では推測が困難なパスワードを使用すべきです (SHOULD)。クレデンシャルがユーザーによって入力されるのではなく、デバイスプロビジョニング中にクライアントデバイスに配置される場合、パスワードは少なくとも128ビットのランダム性を持つべきです (SHOULD)。クレデンシャルがユーザーによって入力される場合、パスワード構造に関する現在のベストプラクティスに従うべきです (SHOULD)。

10.2.1. Forming a Request (リクエストの形成)​

リクエストを形成する場合、2つのケースがあります。最初のケースでは、これはクライアントからサーバー（IPアドレスとポートで識別される）への最初のリクエストです。2番目のケースでは、クライアントは以前のリクエスト/レスポンストランザクションが正常に完了した後、後続のリクエストを送信しています。401または438エラー応答の結果としてリクエストを形成することはセクション10.2.3でカバーされており、「後続のリクエスト」とは見なされないため、セクション10.2.1.2で説明されているルールは使用されません。

10.2.1.1. First Request (最初のリクエスト)​

クライアントがサーバー（セクション9のDNS手順が使用される場合はホスト名で識別され、使用されない場合はIPアドレスで識別される）との成功したリクエスト/レスポンストランザクションを完了していない場合、USERNAME、MESSAGE-INTEGRITY、REALM、およびNONCE属性を省略すべきです (SHOULD)。言い換えれば、最初のリクエストは、認証やメッセージ完全性が適用されていないかのように送信されます。

10.2.1.2. Subsequent Requests (後続のリクエスト)​

リクエスト/レスポンストランザクションが正常に完了すると、サーバーはクライアントにレルムとナンスを提供し、クライアントは認証に使用したユーザー名とパスワードを選択しています。クライアントは、サーバーとの後続の通信のために、ユーザー名、パスワード、レルム、ナンスをキャッシュすべきです (SHOULD)。クライアントが後続のリクエストを送信する場合、これらのキャッシュされた値を持つUSERNAME、REALM、NONCE属性を含めるべきです (SHOULD)。また、キャッシュされたパスワードを使用してセクション15.4で説明されているように計算されたMESSAGE-INTEGRITY属性を含めるべきです (SHOULD)。

10.2.2. Receiving a Request (リクエストの受信)​

サーバーがリクエストの基本処理を完了した後、以下にリストされているチェックを指定された順序で実行します:

  • メッセージにMESSAGE-INTEGRITY属性が含まれていない場合、サーバーはエラーコード401 (Unauthorized) のエラー応答を生成しなければなりません (MUST)。この応答にはREALM値を含めなければなりません (MUST)。REALM値はSTUNサーバープロバイダーのドメイン名であることが推奨されます (RECOMMENDED)。応答には、サーバーによって選択されたNONCEを含めなければなりません (MUST)。応答にはUSERNAME属性またはMESSAGE-INTEGRITY属性を含めるべきではありません (SHOULD NOT)。

  • メッセージにMESSAGE-INTEGRITY属性が含まれているが、USERNAME、REALM、またはNONCE属性がない場合、サーバーはエラーコード400 (Bad Request) のエラー応答を生成しなければなりません (MUST)。この応答には、USERNAME、NONCE、REALM、またはMESSAGE-INTEGRITY属性を含めるべきではありません (SHOULD NOT)。

  • NONCEが有効でなくなった場合、サーバーはエラーコード438 (Stale Nonce) のエラー応答を生成しなければなりません (MUST)。この応答にはNONCE属性とREALM属性を含めなければならず (MUST)、USERNAME属性またはMESSAGE-INTEGRITY属性を含めるべきではありません (SHOULD NOT)。サーバーは追加のセキュリティを提供するためにナンスを無効にすることができます。ガイダンスについては、[RFC2617]のセクション4.3を参照してください。

  • USERNAME属性のユーザー名が有効でない場合、サーバーはエラーコード401 (Unauthorized) のエラー応答を生成しなければなりません (MUST)。この応答にはREALM値を含めなければなりません (MUST)。REALM値はSTUNサーバープロバイダーのドメイン名であることが推奨されます (RECOMMENDED)。応答には、サーバーによって選択されたNONCEを含めなければなりません (MUST)。応答にはUSERNAME属性またはMESSAGE-INTEGRITY属性を含めるべきではありません (SHOULD NOT)。

  • USERNAME属性のユーザー名に関連付けられたパスワードを使用して、セクション15.4で説明されているようにメッセージ完全性の値を計算します。結果の値がMESSAGE-INTEGRITY属性の内容と一致しない場合、サーバーはエラー応答でリクエストを拒否しなければなりません (MUST)。この応答はエラーコード401 (Unauthorized) を使用しなければなりません (MUST)。REALM属性とNONCE属性を含めなければならず (MUST)、USERNAME属性またはMESSAGE-INTEGRITY属性を含めるべきではありません (SHOULD NOT)。

これらのチェックが通過すると、サーバーはリクエストの処理を続行します。サーバーによって生成される応答（上記のケースを除く）には、リクエストの認証に使用されたユーザー名とパスワードを使用して計算されたMESSAGE-INTEGRITY属性を含めなければなりません (MUST)。REALM、NONCE、USERNAME属性は含めるべきではありません (SHOULD NOT)。

10.2.3. Receiving a Response (レスポンスの受信)​

応答がエラーコード401 (Unauthorized) のエラー応答である場合、クライアントは新しいトランザクションでリクエストを再試行すべきです (SHOULD)。このリクエストには、エラー応答のREALMに対する適切なユーザー名としてクライアントによって決定されたUSERNAMEを含めなければなりません (MUST)。リクエストには、エラー応答からコピーされたREALMを含めなければなりません (MUST)。リクエストには、エラー応答からコピーされたNONCEを含めなければなりません (MUST)。リクエストには、USERNAME属性のユーザー名に関連付けられたパスワードを使用して計算されたMESSAGE-INTEGRITY属性を含めなければなりません (MUST)。クライアントが前回の試行からUSERNAMEまたはREALMまたはその関連パスワードを変更していない場合、この再試行を実行してはなりません (MUST NOT)。

応答がエラーコード438 (Stale Nonce) のエラー応答である場合、クライアントは438 (Stale Nonce) 応答で提供された新しいNONCEを使用してリクエストを再試行しなければなりません (MUST)。この再試行には、USERNAME、REALM、MESSAGE-INTEGRITYも含めなければなりません (MUST)。

クライアントは応答（成功または失敗）内のMESSAGE-INTEGRITY属性を探します。存在する場合、クライアントは、リクエストに使用したのと同じパスワードを使用して、セクション15.4で定義されているように応答のメッセージ完全性を計算します。結果の値がMESSAGE-INTEGRITY属性の内容と一致する場合、応答は認証されたと見なされます。値が一致しない場合、またはMESSAGE-INTEGRITYが存在しない場合、応答は、まるで受信されなかったかのように破棄されなければなりません (MUST)。これは、該当する場合、再送信が継続されることを意味します。

に最終更新