Skip to content

Instantly share code, notes, and snippets.

@shinyoshiaki

shinyoshiaki/rfc8489ja.txt

Created February 22, 2020 10:53
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save shinyoshiaki/ca223a8af6771d6f0d44f2b49edf6eed to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save shinyoshiaki/ca223a8af6771d6f0d44f2b49edf6eed to your computer and use it in GitHub Desktop.
Download ZIP
Raw
rfc8489ja.txt
ISSN：2070-1721 J. Rosenberg Five9 D. Wing Citrix R. Mahy Unaffiliated P. Matthews Nokia 2月2020
NATのセッショントラバーサルユーティリティ（STUN）
概要
NATのセッショントラバーサルユーティリティ（STUN）は、NATトラバーサルを扱う他のプロトコルのツールとして機能するプロトコルです. エンドポイントはこれを使用して、NATによって割り当てられたIPアドレスとポートを判別できます. また、2つのエンドポイント間の接続を確認したり、NATバインディングを維持するキープアライブプロトコルとして使用することもできます. STUNは多くの既存のNATで動作し、それらからの特別な動作を必要としません.
STUNは、それ自体はNATトラバーサルソリューションではありません. むしろ、NATトラバーサルソリューションのコンテキストで使用されるツールです.
このドキュメントはRFC 5389を廃止します.
このドキュメントは、Internet Engineering Task Force（IETF）の製品です. IETFコミュニティのコンセンサスを表しています. これは公開レビューを受けており、Internet Engineering Steering Group（IESG）による公開が承認されています. インターネット標準の詳細については、RFC 7841のセクション2を参照してください.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8489で入手できます.
著作権表示
著作権（c）2020 IETF Trustおよび文書作成者として特定された人物. 全著作権所有.
このドキュメントは、このドキュメントの公開日に有効なBCP 78およびIETFトラストのIETFドキュメントに関連する法的条項（https://trustee.ietf.org/license-info）の対象となります. これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているので、注意深く確認してください. このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストを含める必要があり、Simplified BSD Licenseに記載されている保証なしで提供されます.
1.はじめに
この仕様で定義されているプロトコル、NATのセッショントラバーサルユーティリティ（STUN）は、ネットワークアドレス変換（NAT）を処理するためのツールを提供します. エンドポイントがプライベートIPアドレスとポートに対応するNATによって割り当てられたIPアドレスとポートを決定する手段を提供します. また、エンドポイントがNATバインディングを有効に保つ方法も提供します. 一部の拡張機能では、プロトコルを使用して、2つのエンドポイント間で接続チェックを行う[RFC8445]、または2つのエンドポイント間でパケットを中継する[RFC5766]ことができます.
この仕様では、ツールの性質に合わせて、拡張可能なパケット形式を定義し、複数のトランスポートプロトコルでの動作を定義し、2つの形式の認証を提供します.
STUNは、1つ以上のNATトラバーサルソリューションのコンテキストで使用することを目的としています. これらのソリューションは「STUN Usages」として知られています. 各使用法は、NATトラバーサルソリューションを実現するためにSTUNがどのように利用されるかを説明しています. 通常、使用法は、STUNメッセージが送信されるタイミング、含めるオプション属性、使用するサーバー、および使用する認証メカニズムを示します. Interactive Connectivity Establishment（ICE）[RFC8445]は、STUNの使用法の1つです. SIP Outbound [RFC5626]は、STUNのもう1つの使用法です. 場合によっては、使用にはSTUNの拡張が必要になります. STUN拡張は、新しいメソッド、属性、またはエラー応答コードの形式にすることができます. STUNの使用法の詳細については、セクション13を参照してください.
2.動作の概要
このセクションは説明のみです.
/-----\
// STUN \\
| Server |
\\ //
\-----/
+--------------+ Public Internet
................| NAT 2 |.......................
+--------------+
+--------------+ Private Network 2
................| NAT 1 |.......................
+--------------+
/-----\
// STUN \\
| Client |
\\ // Private Network 1
\-----/
Figure 1: One Possible STUN Configuration
可能なSTUN構成の1つを図1に示します. この構成には、STUNプロトコルを実装する2つのエンティティ（STUNエージェントと呼ばれます）があります. 図の下のエージェントは、プライベートネットワーク1に接続されているクライアントです. このネットワークはNAT 1を介してプライベートネットワーク2に接続します. プライベートネットワーク2はNAT 2を介してパブリックインターネットに接続します. 、パブリックインターネット上にあります.
STUNはクライアント/サーバープロトコルです. 2種類のトランザクションをサポートしています. 1つは、クライアントがサーバーに要求を送信し、サーバーが応答を返す要求/応答トランザクションです. 2つ目は、エージェント（クライアントまたはサーバー）が応答を生成しない指示を送信する指示トランザクションです. 両方のタイプのトランザクションには、ランダムに選択された96ビットの番号であるトランザクションIDが含まれます. 要求/応答トランザクションの場合、このトランザクションIDを使用すると、クライアントは応答を生成した要求に応答を関連付けることができます. 指示の場合、トランザクションIDはデバッグの補助として機能します.
すべてのSTUNメッセージは、メソッド、クラス、およびトランザクションIDを含む固定ヘッダーで始まります. メソッドは、これがさまざまな要求または指示のどれであるかを示します. この仕様では、Bindingという1つのメソッドのみが定義されていますが、他のドキュメントでは他のメソッドが定義されることが期待されています. クラスは、これが要求、成功応答、エラー応答、または指示であるかどうかを示します. 固定ヘッダーに続いて、特定のメッセージの追加情報を伝達するType-Length-Value拡張であるゼロ個以上の属性が続きます.
このドキュメントでは、「バインディング」という単一のメソッドを定義しています. Bindingメソッドは、要求/応答トランザクションまたは指示トランザクションで使用できます. 要求/応答トランザクションで使用する場合、Bindingメソッドを使用して、NATがSTUNクライアントに割り当てた特定のバインディングを決定できます. 要求/応答または指示トランザクションのいずれかで使用される場合、Bindingメソッドを使用してこれらのバインディングを維持することもできます.
バインディングリクエスト/レスポンストランザクションでは、バインディングリクエストがSTUNクライアントからSTUNサーバーに送信されます. バインディング要求がSTUNサーバーに到着すると、STUNクライアントとSTUNサーバー間の1つ以上のNATを通過した可能性があります（図1には、このようなNATが2つあります）. バインディング要求メッセージがNATを通過すると、NATはパケットのソーストランスポートアドレス（つまり、ソースIPアドレスとソースポート）を変更します. その結果、サーバーが受信した要求の送信元トランスポートアドレスは、サーバーに最も近いNATによって作成されたパブリックIPアドレスとポートになります. これは「reflexive transport address」と呼ばれます. STUNサーバーは、そのソーストランスポートアドレスをSTUNバインディング応答のXOR-MAPPED-ADDRESS属性にコピーし、バインディング応答をSTUNクライアントに送り返します. このパケットがNATを通過すると、NATはIPヘッダーの宛先トランスポートアドレスを変更しますが、STUN応答の本文内のXOR-MAPPED-ADDRESS属性のトランスポートアドレスは変更されません. このようにして、クライアントは、STUNサーバーに関して最も外側のNATによって割り当てられたreflexive transport addressを学習できます.
一部の使用法では、STUNは他のプロトコル（[RFC8445]および[RFC5626]など）と多重化する必要があります. これらの使用法では、パケットを検査し、それがSTUNパケットであるかどうかを判断する方法が必要です. STUNは、この目的に使用できる固定値を持つSTUNヘッダーに3つのフィールドを提供します. これで十分でない場合は、STUNパケットにFINGERPRINT値を含めることもできます. この値はさらにパケットを区別するために使用できます.
STUNは、「メカニズム」と呼ばれる、使用法が使用することを決定できる一連のオプションの手順を定義します. これらのメカニズムには、DNSディスカバリ、代替サーバーへのリダイレクト手法、逆多重化のためのfingerprint属性、2つの認証およびメッセージ整合性交換が含まれます. 認証メカニズムは、ユーザー名、パスワード、およびメッセージ整合性値の使用を中心に展開します. この仕様では、2つの認証メカニズム、long-term credential mechanismとshort-term credential mechanismが定義されています. 各使用法は、その使用法で許可されるメカニズムを指定します.
long-term credential mechanismでは、クライアントとサーバーは事前にプロビジョニングされたユーザー名とパスワードを共有し、HTTP [RFC7616]に定義されているものに触発されたダイジェストチャレンジ/レスポンス交換を実行します. short-term credential mechanismでは、クライアントとサーバーは、STUN交換の前に何らかのアウトオブバンド方式でユーザー名とパスワードを交換します. たとえば、ICEの使用法[RFC8445]では、2つのエンドポイントは帯域外シグナリングを使用してユーザー名とパスワードを交換します. これらは、要求と応答を完全に保護および認証するために使用されます. チャレンジやノンスは使用されていません.
3.用語
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONAL」この文書の「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように、ここに示すようにすべての大文字で表示される場合にのみ解釈されます.
4.定義
STUNエージェント：STUNエージェントは、STUNプロトコルを実装するエンティティです. エンティティは、STUNクライアントまたはSTUNサーバーのいずれかです.
STUNクライアント：STUNクライアントは、STUN要求を送信し、STUN応答とSTUN指示を受信するエンティティです. STUNクライアントはインジケーションを送信することもできます. この仕様では、「STUNクライアント」と「クライアント」という用語は同義語です.
STUNサーバー：STUNサーバーは、STUN要求とSTUN指示を受信し、STUN応答を送信するエンティティです. STUNサーバーはインジケーションを送信することもできます. この仕様では、「STUNサーバー」と「サーバー」という用語は同義語です. トランスポートアドレス：IPアドレスとポート番号の組み合わせ（UDPまたはTCPポート番号など）.
reflexive transport address：IPネットワーク上の別のホスト（通常はSTUNサーバー）から見たクライアントを識別する、クライアントが学習したトランスポートアドレス. クライアントと他のホストの間にNATが介在する場合、reflexive transport addressは、NATのパブリック側でクライアントに割り当てられたマッピングアドレスを表します. reflexive transport addressは、STUN応答のマップされたアドレス属性（MAPPED-ADDRESSまたはXOR-MAPPED-ADDRESS）から学習されます.
Mapped Address：reflexive addressと同じ意味. この用語は、歴史的な理由と、MAPPED-ADDRESSおよびXOR-MAPPED-ADDRESS属性の命名のためにのみ保持されます.
Long-Term Credential：クライアントとサーバー間の共有秘密を表すユーザー名と関連パスワード. 通常、Long-Term Credentialは、サブスクライバーがサービスに登録するときにクライアントに付与され、サブスクライバーがサービスを終了するか、資格情報を明示的に変更するまで持続します.
Long-Term Password：Long-Term Credentialからのパスワード.
Short-Term Credential：クライアントとサーバー間の共有秘密を表す一時的なユーザー名と関連パスワード. Short-Term Credentialは、STUN交換に先立って、クライアントとサーバー間の何らかのプロトコルメカニズムを通じて取得されます. Short-Term Credentialには、特定の時間（5分など）またはイベント（Session Initiation Protocol（SIP）[RFC3261]ダイアログの終了など）に基づく明示的な時間スコープがあります. Short-Term Credentialの特定の範囲は、アプリケーションの使用状況によって定義されます.
短期パスワード：Short-Term Credentialのパスワードコンポーネント.
STUNインディケーション：応答を受信しないSTUNメッセージ.
Attribute：STUNメッセージに追加できるType-Length-Value（TLV）オブジェクトのSTUN用語. 属性は、内包必須と内包オプションの2つのタイプに分けられます. STUNエージェントは、理解できない理解オプション属性を安全に無視できますが、理解できない理解必須属性が含まれている場合、メッセージを正常に処理できません.
RTO：再送信タイムアウト. 要求の送信からその要求の最初の再送信までの初期期間を定義します.
5. STUNメッセージ構造
STUNメッセージは、ネットワーク指向形式を使用してバイナリでエンコードされます（最上位バイトまたはオクテットが最初で、一般にビッグエンディアンとしても知られています）. 送信順序は、[RFC0791]の付録Bで詳細に説明されています. 特に明記されていない限り、数値定数は10進数です（基数10）.
すべてのSTUNメッセージは、20バイトのヘッダーとそれに続くゼロ個以上の属性で構成されます. STUNヘッダーには、STUNメッセージタイプ、メッセージ長、マジックCookie、およびトランザクションIDが含まれています.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0| STUN Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Transaction ID (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of STUN Message Header
すべてのSTUNメッセージの最上位2ビットはゼロでなければなりません. これは、STUNが同じポート上の他のプロトコルと多重化されている場合に、STUNパケットを他のプロトコルと区別するために使用できます.
メッセージタイプは、STUNメッセージのメッセージクラス（要求、成功応答、エラー応答、または表示）とメッセージメソッド（主要な機能）を定義します. 4つのメッセージクラスがありますが、STUNには2種類のトランザクションしかありません. 要求/応答トランザクション（要求メッセージと応答メッセージで構成される）と指示トランザクション（単一の指示メッセージで構成される）です. 応答クラスはエラー応答と成功応答に分割され、STUNメッセージの迅速な処理を支援します.
STUNメッセージタイプフィールドは、さらに次の構造に分解されます.
0 1
2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+-+-+-+-+-+-+-+-+-+-+-+-+
|M |M |M|M|M|C|M|M|M|C|M|M|M|M|
|11|10|9|8|7|1|6|5|4|0|3|2|1|0|
+--+--+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format of STUN Message Type Field
ここで、STUNメッセージタイプフィールドのビットは、最上位（M11）から最下位（M0）として示されています. M11からM0は、メソッドの12ビットエンコーディングを表します. C1とC0は、クラスの2ビットエンコーディングを表します. 0b00のクラスは要求、0b01のクラスは指示、0b10のクラスは成功応答、0b11のクラスはエラー応答です. この仕様では、Bindingという単一のメソッドを定義しています. メソッドとクラスは直交しているため、各メソッドについて、そのメソッドに対してリクエスト、成功応答、エラー応答、および表示が可能です. 新しいメソッドを定義する拡張は、そのメソッドに許可されるクラスを示さなければなりません.
たとえば、バインディングリクエストにはclass = 0b00（リクエスト）およびmethod = 0b000000000001（バインディング）があり、最初の16ビットに0x0001としてエンコードされます. バインディング応答には、class = 0b10（成功応答）とmethod = 0b000000000001があり、最初の16ビットに0x0101としてエンコードされます.
注：この不幸なエンコーディングは、ビットフィールドを使用して指示メッセージ、成功応答、およびエラー応答をエンコードすることを考慮しなかった[RFC3489]の値の割り当てによるものです.
Magic Cookieフィールドには、ネットワークバイト順で固定値0x2112A442を含める必要があります. [RFC3489]では、Magic Cookieフィールドを構成する32ビットはトランザクションIDの一部でした. この場所にマジックCookieを配置すると、サーバーは、クライアントが[RFC5389]によってSTUNに追加された特定の属性を理解するかどうかを検出できます. さらに、STUNが同じポート上の他のプロトコルと多重化されている場合、STUNパケットを他のプロトコルのパケットと区別するのに役立ちます.
トランザクションIDは96ビットの識別子で、STUNトランザクションを一意に識別するために使用されます. 要求/応答トランザクションの場合、トランザクションIDは要求のSTUNクライアントによって選択され、サーバーによって応答にエコーされます. 指示の場合、指示を送信するエージェントによって選択されます. 主にリクエストとレスポンスを相関させる役割を果たしますが、特定のタイプの攻撃を防ぐのに役立つ小さな役割も果たします. サーバーは、トランザクションIDをキーとして使用して、すべてのクライアントにわたって各トランザクションを一意に識別します. そのため、トランザクションIDは間隔0 .. 2 ** 96-1から均一かつランダムに選択する必要があり、暗号的にランダムでなければなりません. 同じリクエストを再送信すると、同じトランザクションIDが再利用され、ただし、新しいリクエストが以前のリクエストとビット単位で同一で、同じトランスポートアドレスから同じIPアドレスに送信されない限り、クライアントは新しいトランザクションに新しいトランザクションIDを選択する必要があります. 成功およびエラー応答には、対応する要求と同じトランザクションIDを含める必要があります. エージェントが同じポートでSTUNサーバーおよびSTUNクライアントとして機能している場合、エージェントによって送信された要求のトランザクションIDは、エージェントによって受信された要求のトランザクションIDとは関係がありません.
メッセージの長さは、20バイトのSTUNヘッダーを含まず、バイト単位でメッセージのサイズを含まなければなりません. すべてのSTUN属性は4バイトの倍数にパディングされるため、このフィールドの最後の2ビットは常にゼロです. これは、STUNパケットを他のプロトコルのパケットと区別する別の方法を提供します.
ヘッダーのSTUN固定部分に続くのは、0個以上の属性です. 各属性はTLV（Type-Length-Value）エンコードされています. エンコーディングと属性自体の詳細は、セクション14で説明します.
6.基本プロトコル手順
このセクションでは、STUNプロトコルの基本手順を定義します. メッセージの形成方法、送信方法、受信時の処理方法について説明します. また、Bindingメソッドの詳細な処理も定義します. このドキュメントの他のセクションでは、特定の状況で使用することを選択できるオプションの手順について説明します. 他のドキュメントでは、新しいメソッド、新しい属性、または新しいエラー応答コードを追加することにより、STUNに他の拡張機能を定義できます.
6.1. リクエストまたは表示の作成
要求または指示メッセージを作成する場合、エージェントはヘッダーを作成するときにセクション5の規則に従う必要があります. また、メッセージクラスは「要求」または「指示」（必要に応じて）でなければならず、メソッドはバインディングまたは別のドキュメントで定義されたメソッドでなければなりません.
次に、エージェントは、メソッドまたは使用法によって指定された属性を追加します. たとえば、一部の使用法では、エージェントが認証方法（セクション9）またはFINGERPRINT属性（セクション7）を使用するように指定できます.
エージェントがリクエストを送信している場合、リクエストにソフトウェア属性を追加する必要があります. エージェントは、方法に応じて、表示にソフトウェア属性を含めることができます. STUNの拡張機能では、新しい適応症でソフトウェアが役立つかどうかを検討する必要があります. SOFTWARE属性を含めると、セキュリティに影響する可能性があることに注意してください. 詳細については、セクション16.1.2を参照してください.
認証のないBindingメソッドの場合、使用法で特に指定されていない限り、属性は不要です.
UDPまたはDTLS-over-UDP [RFC6347]を介して送信されるすべてのSTUNメッセージは、既知の場合、パスMTU未満である必要があります.
UDPのパスMTUが不明な場合、メッセージは576バイトとIPv4 [RFC1122]の最初のホップMTUおよびIPv6 [RFC8200]の1280バイトの小さい方である必要があります. この値は、IPパケットの全体サイズに対応します. その結果、IPv4の場合、実際のSTUNメッセージは548バイト未満である必要があります（576から20バイトのIPヘッダー、8バイトのUDPヘッダー、IPオプションが使用されていない場合）.
DTLS-over-UDPのパスMTUが不明な場合は、前の段落で説明したルールを調整して、（13バイト）DTLSレコードヘッダーのサイズ、メッセージ認証コード（MAC）サイズ、およびパディングサイズ.
STUNは、要求がMTUよりも小さいが、応答がMTUよりも大きい場合を処理する機能を提供しません. この制限がSTUNの問題になることは想定されていません. MTU制限は、MTU特性[RFC5780]のプローブにSTUN自体が使用されている場合を説明するために、MUSTではなく、SHOULDです. また、STUNを使用してこのようなメカニズムのないプロトコルにPath MTU Discoveryを追加するフレームワークについては、[STUN-PMTUD]も参照してください. このアプリケーションまたは同様のアプリケーション以外では、MTU制約に従う必要があります.
6.2. リクエストまたはインディケーションの送信
次に、エージェントは要求または指示を送信します. このドキュメントは、UDP、TCP、TLS-over-TCP、またはDTLS-over-UDPでSTUNメッセージを送信する方法を指定します. 将来、他のトランスポートプロトコルが追加される可能性があります. STUNの使用法では、使用するトランスポートプロトコルと、エージェントが受信者のIPアドレスとポートを決定する方法を指定する必要があります. セクション8では、使用法が使用を選択する可能性のあるサーバーのIPアドレスとポートを決定するDNSベースの方法について説明します.
いつでも、クライアントは、同じSTUNサーバーで複数の未解決のSTUN要求を持っている場合があります（つまり、異なるトランザクションIDで進行中の複数のトランザクション）. 他の制限がない
新しいトランザクションの速度（接続チェックのためにICEによって指定されたトランザクションや、STUNがTCPを介して実行される場合など）、クライアントは、同じサーバーに対する未処理のトランザクションを10個に制限する必要があります.
6.2.1. UDPまたはDTLS-over-UDPで送信する
STUN over UDPまたはSTUN over DTLS-over-UDP [RFC7350]を実行している場合、ネットワークによってSTUNメッセージがドロップされる可能性があります. STUN要求/応答トランザクションの信頼性は、クライアントアプリケーション自体による要求メッセージの再送信によって実現されます. STUN表示は再送信されません. したがって、UDPまたはDTLS-over-UDPを介した指示トランザクションは信頼できません.
クライアントは、RTO（ "Retransmission TimeOut"）の間隔で始まるSTUN要求メッセージを再送信する必要があります（再送信のたびに2倍になります）. RTOは往復時間（RTT）の推定値であり、[RFC6298]で説明されているように計算されますが、2つの例外があります. まず、RTOの初期値は500ミリ秒以上である必要があります. この「SHOULD」の例外ケースは、他のメカニズムを使用して輻輳しきい値（固定レートストリームのICEで定義されたものなど）を導出する場合、またはネットワーク容量が既知の非インターネット環境でSTUNを使用する場合です. 固定回線アクセスリンクでは、500ミリ秒の値が推奨されます. 第二に、RTOの値は最も近い秒に切り上げられるべきではありません. むしろ、1ミリ秒の精度を維持する必要があります. TCPと同様に、Karn 'の使用 sアルゴリズムが推奨されます[KARN87]. STUNに適用される場合、RTTの見積もりは、リクエストの再送信をもたらすSTUNトランザクションから計算されるべきではないことを意味します.
RTOの値は、トランザクションの完了後にクライアントによってキャッシュされ、同じサーバーへの次のトランザクションのRTOの開始値として使用される必要があります（IPアドレスの同等性に基づく）. 過去10分間に同じサーバーでトランザクションが発生しなかった場合、値は古いものと見なされ、破棄される必要があります.
再送信は、応答が受信されるか、Rc要求の合計が送信されるまで続きます. Rcは設定可能であり、デフォルトは7である必要があります（最後の要求の後、RmにRTOが応答なしで経過した時間に等しい期間が続く場合（この最終要求のみが実際に成功した場合に応答を得るための十分な時間を提供します）、クライアントは、トランザクションが失敗したと見なすべきです. Rmは設定可能であり、デフォルトは16である必要があります. ハードICMPエラー[RFC1122]があった場合、UDPまたはDTLS-over-UDPを介したSTUNトランザクションも失敗したと見なされます. たとえば、RTOが500ミリ秒の場合、リクエストは0ミリ秒、500ミリ秒、1500ミリ秒、3500ミリ秒、7500ミリ秒、15500ミリ秒、および31500ミリ秒の時間に送信されます. クライアントが39500ミリ秒後に応答を受信しなかった場合、クライアントはトランザクションがタイムアウトしたと見なします. 6.2.2.
TCPおよびTLS-over-TCP [RFC8446]の場合、クライアントはサーバーへのTCP接続を開きます.
STUNの一部の使用法では、STUNはTCP接続を介した唯一のプロトコルです. この場合、追加のフレーミングまたは逆多重化を使用せずに送信できます. 他の用途、または他の拡張機能では、TCP接続を介して他のデータと多重化される場合があります. その場合、エージェントが完全なSTUNメッセージと完全なアプリケーション層メッセージを抽出できるように、使用法または拡張機能によって指定された何らかの種類のフレーミングプロトコル上でSTUNを実行する必要があります. セクション8のDNS手順で検出された既知のポートで実行されるSTUNサービスは、STUN専用であり、他のデータと多重化されたSTUN用ではありません. したがって、これらのサーバーへの接続にはフレーミングプロトコルは使用されません. 追加のフレーミングが使用される場合、使用法は、クライアントがそれを適用する方法を知る方法と、接続するポートを指定します.
STUN over TCPおよびTLS-over-TCPの信頼性はTCP自体によって処理され、STUNプロトコルレベルでの再送信はありません. ただし、要求/応答トランザクションの場合、クライアントが要求メッセージを送信してからTi秒経過しても応答を受信しなかった場合、クライアントはトランザクションがタイムアウトしたと見なします. Tiは構成可能でなければならず（SHOULD）、デフォルトは39.5秒です. この値は、デフォルトの初期RTOのTCPタイムアウトとUDPタイムアウトを等しくするために選択されています.
また、クライアントがTCP接続を確立できない場合、またはTCP接続がリセットされるか、応答を受信する前に失敗した場合、進行中の要求/応答トランザクションは失敗したと見なされます.
クライアントは、単一のTCP（またはTLS-over-TCP）接続を介して複数のトランザクションを送信できます. また、前の要求に対する応答を受信する前に、別の要求を送信できます. クライアントは次の状態になるまで接続を開いたままにする必要があります.
oその接続を介して送信する追加のSTUN要求または指示がない.
oその接続を介して送信されたSTUN要求を通じて学習されたリソース（マップされたアドレス（MAPPED-ADDRESSまたはXOR-MAPPED-ADDRESS）やリレーされたアドレス[RFC5766]など）を使用する予定はありません.
oそのポートで他のアプリケーションプロトコルを多重化し、それらの他のプロトコルの使用を終了した場合、
oその学習したポートをリモートピアで使用している場合、一部のTCP NATトラバーサル技術（たとえば[RFC6544]）で要求されているように、そのリモートピアとの通信を確立しています.
最終的なキープアライブメカニズムの詳細は、各STUNの使用法に任されています. いずれにせよ、アイドル状態のTCP接続が機能しなくなったためにトランザクションが失敗した場合、クライアントはRSTを送信して新しいTCP接続を開こうとする必要があります.
サーバー側では、サーバーは、接続がタイムアウトしたと判断した場合を除き（たとえば、クライアントがネットワークから切断したため）、接続を開いたままにしてクライアントを閉じます. クライアントが学習したバインディングは、接続が開いたままである場合にのみ、NATの介入において有効のままになります. クライアントだけがバインディングが必要な時間を知っています. 応答が送信されていない接続を介して要求が受信された場合、サーバーは接続を閉じるべきではありません. サーバーは、応答を送信するためにクライアントへの接続を開いてはいけません. サーバーは、過負荷の場合の接続管理に関するベストプラクティスに従う必要があります.
6.2.3. TLS-over-TCPまたはDTLS-over-UDPを介した送信
TLS-over-TCPまたはDTLS-over-UDPでSTUNを単独で実行する場合、TLS_DHE_RSA_WITH_AES_128_GCM_SHA256およびTLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256暗号スイートを実装する必要があります（このプロトコルの古いバージョンとの互換性のため）. 他の暗号スイートが実装される場合があります. TLSバージョン1.3 [RFC8446]以降のバージョンを実装するSTUNクライアントとサーバーは、それらの仕様からの必須の暗号スイートを実装するためにも必要であり、それらの仕様のサポートを検出した場合、非推奨の暗号スイートの使用を無効にする必要があることに注意してください. Perfect Forward Secrecy（PFS）暗号スイートは、非PFS暗号スイートよりも優先される必要があります. （単一の）DESおよびRC4に基づく脆弱性など、既知の脆弱性を持つ暗号スイートは使用しないでください. 実装では、TLSレベルの圧縮を無効にする必要があります.
これらの推奨事項は、[BCP195]の推奨事項の一部であり、TLSまたはDTLSを使用したSTUN用法の実装と展開が従わなければなりません.
TLS証明書メッセージを受信すると、クライアントは証明書を検証し、証明書によって識別されたサイトを検査する必要があります. 証明書が無効または取り消されている場合、または適切な関係者を特定できない場合、クライアントはSTUNメッセージを送信したり、STUNトランザクションを続行したりしてはなりません. クライアントはサーバーの身元を確認する必要があります. それを行うために、[RFC6125]で定義された識別手順に従います. タイプDNS-IDまたはCN-IDの識別子を含む証明書、オプションで左端のラベルとしてワイルドカード文字を使用しますが、タイプSRV-IDまたはURIは使用しません-ID.
TLS-over-TCP接続またはDTLS-over-UDPアソシエーションを介してSTUNを他のプロトコルと多重化して実行する場合、必須の暗号スイートとTLS処理手順は、これらのプロトコルで定義されたとおりに動作します.
6.3. STUNメッセージの受信
このセクションでは、STUNメッセージの処理を指定します. ここで指定される処理は、この仕様で定義されているSTUNメッセージ用です. 後方互換性のための追加ルールはセクション11で定義されています. これらの追加手順はオプションであり、使用法はそれらを利用することを選択できます. 最初に、クラスに依存しない一連の処理操作が適用されます. これに続いて、クラス固有の処理が続きます. これについては、次のサブセクションで説明します.
STUNエージェントは、STUNメッセージを受信すると、最初にメッセージがセクション5の規則に従っていることを確認します. 最初の2ビットが0であること、Magic Cookieフィールドに正しい値があること、メッセージの長さが適切であること、メソッド値がサポートされているメソッドであること. メッセージクラスが特定のメソッドに許可されていることを確認します. メッセージクラスが「成功応答」または「エラー応答」の場合、エージェントはトランザクションIDがまだ進行中のトランザクションと一致することを確認します. FINGERPRINT拡張機能が使用されている場合、エージェントはFINGERPRINT属性が存在し、正しい値が含まれていることを確認します. エラーが検出された場合、メッセージは静かに破棄されます. STUNが別のプロトコルと多重化されている場合、エラーは、これが実際にはSTUNメッセージではないことを示している場合があります. この場合、エージェントはメッセージを別のプロトコルとして解析しようとする必要があります.
その後、STUNエージェントは、使用法が指定した認証メカニズムに必要なチェックを行います（セクション9を参照）.
認証チェックが完了すると、STUNエージェントはメッセージ内の不明な属性と既知だが予期しない属性をチェックします. 不明な理解オプション属性は、エージェントによって無視されなければなりません. 既知だが予期しない属性は、エージェントによって無視されるべきである[SHOULD]. 不明な理解が必要な属性は、メッセージクラスに依存する処理を引き起こします. これについては以下で説明します. この時点で、以降の処理はリクエストのメッセージクラスに依存します.
6.3.1. リクエストの処理
要求に1つ以上の不明な理解が必要な属性が含まれている場合、サーバーはエラーコード420（不明な属性）のエラー応答で応答し、不明な理解が必要な属性をリストする応答にUNKNOWN-ATTRIBUTES属性を含めます.
それ以外の場合、サーバーはメソッドまたは特定の使用法に必要な追加のチェックを行います. すべてのチェックが成功した場合、サーバーは以下で説明するように成功応答を作成します.
UDPまたはDTLS-over-UDPを介して実行される場合、サーバーが受信した要求は、トランザクションの最初の要求であるか、再送信である可能性があります. サーバーは、次のプロパティが保持されるように再送信に応答する必要があります. クライアントが元の要求に送信された応答ではなく、再送信に対する応答を受信した場合、クライアントとサーバーの全体的な状態は、元の再送信に対する応答が受信されるか、両方の応答が受信される場合（この場合、クライアントは最初の応答を使用します）. この要件を満たす最も簡単な方法は、サーバーがUDPまたはDTLS-over-UDPで受信したすべてのトランザクションIDと、対応する過去40秒間の応答を記憶することです. しかしながら、これには、サーバーが状態を保持する必要があり、認証されていない要求には不適切です. 別の方法は、リクエストを再処理し、レスポンスを再計算することです. 後者の手法は、i等であるリクエストにのみ適用する必要があり（システムの全体的な状態に影響を与えることなく同じリクエストを安全に繰り返すことができる場合、リクエストはi等と見なされます）、同じリクエストに対して同じ成功応答を返します. Bindingメソッドはべき等であると見なされます. 反射トランスポートアドレスの値を変更する可能性のある特定のまれなネットワークイベントがあり、異なる成功応答で異なるマッピングアドレスが生じることに注意してください. STUNの拡張では、トランザクション状態を保存しないサーバーでの要求の再送信の意味を説明する必要があります. 別の方法は、リクエストを再処理し、レスポンスを再計算することです. 後者の手法は、i等であるリクエストにのみ適用する必要があり（システムの全体的な状態に影響を与えることなく同じリクエストを安全に繰り返すことができる場合、リクエストはi等と見なされます）、同じリクエストに対して同じ成功応答を返します. Bindingメソッドはべき等であると見なされます. 反射トランスポートアドレスの値を変更する可能性のある特定のまれなネットワークイベントがあり、異なる成功応答で異なるマッピングアドレスが生じることに注意してください. STUNの拡張では、トランザクション状態を保存しないサーバーでの要求の再送信の意味を説明する必要があります. 別の方法は、リクエストを再処理し、レスポンスを再計算することです. 後者の手法は、i等であるリクエストにのみ適用する必要があり（システムの全体的な状態に影響を与えることなく同じリクエストを安全に繰り返すことができる場合、リクエストはi等と見なされます）、同じリクエストに対して同じ成功応答を返します. Bindingメソッドはべき等であると見なされます. 反射トランスポートアドレスの値を変更する可能性のある特定のまれなネットワークイベントがあり、異なる成功応答で異なるマッピングアドレスが生じることに注意してください. STUNの拡張では、トランザクション状態を保存しないサーバーでの要求の再送信の意味を説明する必要があります. 後者の手法は、i等であるリクエストにのみ適用する必要があり（システムの全体的な状態に影響を与えることなく同じリクエストを安全に繰り返すことができる場合、リクエストはi等と見なされます）、同じリクエストに対して同じ成功応答を返します. Bindingメソッドはべき等であると見なされます. 反射トランスポートアドレスの値を変更する可能性のある特定のまれなネットワークイベントがあり、異なる成功応答で異なるマッピングアドレスが生じることに注意してください. STUNの拡張では、トランザクション状態を保存しないサーバーでの要求の再送信の意味を説明する必要があります. 後者の手法は、i等であるリクエストにのみ適用する必要があり（システムの全体的な状態に影響を与えることなく同じリクエストを安全に繰り返すことができる場合、リクエストはi等と見なされます）、同じリクエストに対して同じ成功応答を返します. Bindingメソッドはべき等であると見なされます. 反射トランスポートアドレスの値を変更する可能性のある特定のまれなネットワークイベントがあり、異なる成功応答で異なるマッピングアドレスが生じることに注意してください. STUNの拡張では、トランザクション状態を保存しないサーバーでの要求の再送信の意味を説明する必要があります. 反射トランスポートアドレスの値を変更する可能性のある特定のまれなネットワークイベントがあり、異なる成功応答で異なるマッピングアドレスが生じることに注意してください. STUNの拡張では、トランザクション状態を保存しないサーバーでの要求の再送信の意味を説明する必要があります. 反射トランスポートアドレスの値を変更する可能性のある特定のまれなネットワークイベントがあり、異なる成功応答で異なるマッピングアドレスが生じることに注意してください. STUNの拡張では、トランザクション状態を保存しないサーバーでの要求の再送信の意味を説明する必要があります.
6.3.1.1. 成功またはエラー応答の形成
応答（成功またはエラー）を形成する場合、サーバーはセクション6のルールに従います. 応答のメソッドは要求のメソッドと同じで、メッセージクラスは「成功応答」または「エラー応答」です.
エラー応答の場合、サーバーは上記の処理で指定されたエラーコードを含むERROR-CODE属性を追加する必要があります. 理由句は修正されていませんが、エラーコードに適したものである必要があります. 特定のエラーについては、追加の属性がメッセージに追加されます. これらの属性は、エラーコードが指定されている説明に記載されています. たとえば、420（不明な属性）のエラーコードの場合、サーバーにはUNKNOWN- ATTRIBUTES属性を含める必要があります. 特定の認証エラーにより、属性が追加されます（セクション9を参照）. 拡張機能では、エラーの場合に追加する他のエラーや追加属性を定義できます.
サーバーが認証メカニズムを使用して要求を認証した場合、サーバーは適切な認証属性を応答に追加する必要があります（セクション9を参照）.
サーバーは、特定のメソッドまたは使用法に必要な属性も追加します. さらに、サーバーはメッセージにSOFTWARE属性を追加する必要があります.
Bindingメソッドの場合、使用法で特に指定されていない限り、追加のチェックは不要です. 成功応答を作成するとき、サーバーはXOR-MAPPED-ADDRESS属性を応答に追加します. この属性には、要求メッセージのソース転送アドレスが含まれます. UDPまたはDTLS-over-UDPの場合、これは要求メッセージのソースIPアドレスとソースUDPポートです. TCPおよびTLS-over-TCPの場合、これはサーバーから見たTCP接続のソースIPアドレスおよびソースTCPポートです.
6.3.1.2. 成功またはエラー応答の送信
応答（成功またはエラー）は、要求が受信されたのと同じトランスポートを介して送信されます. 要求がUDPまたはDTLS-over-UDPで受信された場合、応答の宛先IPアドレスとポートは受信した要求メッセージの送信元IPアドレスとポートであり、応答の送信元IPアドレスとポートは受信した要求メッセージの宛先IPアドレスとポート. 要求がTCPまたはTLS-over-TCPで受信された場合、応答は要求が受信されたのと同じTCP接続で返送されます.
サーバーは、要求を受信した順序とは異なる順序で応答を送信できます.
6.3.2. 表示の処理
指示に不明な理解が必要な属性が含まれている場合、指示は破棄され、処理が停止します.
それ以外の場合、エージェントはメソッドまたは特定の使用法が必要とする追加のチェックを行います. すべてのチェックが成功すると、エージェントは指示を処理します. 指示に対して応答は生成されません.
Bindingメソッドの場合、使用法で特に指定されていない限り、追加のチェックや処理は必要ありません. エージェントがメッセージを受信するだけで、介在するNATのバインディングが更新されます.
指示は（要求とは異なり）UDPまたはDTLS-over-UDPを介して再送信されないため、送信エージェントで指示の再送信を処理する必要はありません.
6.3.3. 成功応答の処理
成功応答に不明な理解が必要な属性が含まれている場合、応答は破棄され、トランザクションは失敗したと見なされます.
それ以外の場合、クライアントはメソッドまたは特定の使用法に必要な追加のチェックを行います. すべてのチェックが成功すると、クライアントは成功応答を処理します.
Bindingメソッドの場合、クライアントはXOR-MAPPED-ADDRESS属性が応答に存在することを確認します. クライアントは、指定されたアドレスファミリをチェックします. サポートされていないアドレスファミリの場合、属性を無視する必要があります. 予期しないがサポートされているアドレスファミリである場合（たとえば、バインディングトランザクションがIPv4を介して送信されたが、指定されたアドレスファミリがIPv6である場合）、クライアントは値を受け入れて使用できます（MAY）.
6.3.4. エラー応答の処理
エラー応答に不明な理解必須属性が含まれている場合、またはエラー応答にERROR-CODE属性が含まれていない場合、トランザクションは単に失敗したと見なされます.
それ以外の場合、クライアントは認証メカニズムで指定された処理を実行します（セクション9を参照）. これにより、新しいトランザクションが試行される場合があります.
この時点での処理は、エラーコード、メソッド、および使用法によって異なります. デフォルトのルールは次のとおりです.
oエラーコードが300〜399の場合、クライアントは、ALTERNATE-SERVER拡張（セクション10）が使用されていない限り、トランザクションが失敗したと見なすべきです（SHOULD）. oエラーコードが400〜499の場合、クライアントはトランザクションが失敗したと宣言します. 420（不明な属性）の場合、応答には追加情報を提供するUNKNOWN-ATTRIBUTES属性が含まれている必要があります.
oエラーコードが500から599の場合、クライアントはリクエストを再送信できます（MAY）. そうするクライアントは、これを行う回数を制限しなければなりません. 特定のエラーコードで別の値が指定されていない限り、再送信の回数は4に制限する必要があります.
他のエラーコードがあると、クライアントはトランザクションが失敗したと見なします.
7. FINGERPRINTメカニズム
このセクションでは、同じトランスポートアドレスで2つが多重化されている場合に他のプロトコルのパケットからSTUNメッセージを区別するのに役立つSTUNのオプションメカニズムについて説明します. このメカニズムはオプションであり、STUNの使用法では、使用するかどうかと使用するタイミングを記述する必要があります. FINGERPRINTメカニズムはRFC 3489との後方互換性がなく、そのような互換性が必要な環境では使用できません.
一部の使用法では、STUNメッセージはReal-Time Transport Protocol（RTP）などの他のプロトコルと同じトランスポートアドレスで多重化されます. セクション6で説明した処理を適用するには、最初にSTUNメッセージをアプリケーションパケットから分離する必要があります.
セクション5では、この目的に使用できるSTUNヘッダーの3つの固定フィールドについて説明します. ただし、場合によっては、これらの3つの固定フィールドでは不十分な場合があります.
FINGERPRINT拡張機能を使用すると、エージェントは別のエージェントに送信するメッセージにFINGERPRINT属性を含めます. セクション14.7では、この属性の配置と値について説明しています.
エージェントは、STUNメッセージと思われるものを受信すると、他の基本的なチェックに加えて、メッセージにFINGERPRINT属性が含まれていること、および属性に正しい値が含まれていることもチェックします. セクション6.3では、STUNメッセージの処理全体でFINGERPRINTチェックが実行される時期について説明します. この追加のチェックは、エージェントが他の方法ではSTUNメッセージと思われる他のプロトコルのメッセージを検出するのに役立ちます.
8.サーバーのDNSディスカバリー
このセクションでは、クライアントがDNSを使用してサーバーのIPアドレスとポートを決定できるようにする、STUNのオプションの手順について説明します. STUN使用法は、この拡張機能を使用するかどうか、いつ使用するかを記述する必要があります. この手順を使用するには、クライアントはSTUN URI [RFC7064]を知っている必要があります. 使用法には、クライアントがこのURIを取得する方法も記述する必要があります. ドメイン名が失われた場合、または法的またはその他の理由で変更する必要がある場合、STUN URIをソフトウェアにハードコーディングすることは推奨されません.
クライアントが、バインド要求/応答トランザクションを受け入れるパブリックインターネット上のSTUNサーバーを見つけたい場合、STUN URIスキームは「stun」です. TLSまたはDTLSセッションを介してバインディングリクエスト/レスポンストランザクションを受け入れるSTUNサーバーを見つけたい場合、URIスキームは「スタン」です​​.
「stun」および「stuns」URIの構文は、[RFC7064]のセクション3.1で定義されています. STUNの使用法では、追加のURIスキームを定義できます.
8.1. STUN URIスキームのセマンティクス
「stun」URIの<host>部分にIPアドレスが含まれている場合、このIPアドレスはサーバーへの接続に直接使用されます. IPアドレスを含む「スタン」URIは拒否されなければなりません. 将来のSTUNの拡張または使用は、STUNサーバーを認証し、中間者攻撃を防止する方法を示す限り、この要件を緩和する可能性があります.
URIにIPアドレスが含まれていない場合、<host>部分に含まれるドメイン名は、[RFC2782]で指定されたSRV手順を使用してトランスポートアドレスに解決されます. DNS SRVサービス名は、<scheme>部分のコンテンツです. SRVルックアップのプロトコルは、クライアントがSTUNを実行するトランスポートプロトコルです. UDPの場合は「udp」、TCPの場合は「tcp」です.
RFC 2782の手順に従って、接続するサーバーを決定します. RFC 2782は、SRVレコードのセットがどのようにソートされ、試行されるかの詳細を説明しています. ただし、RFC 2782には、クライアントが「（プロトコル、アドレス、サービス）への接続を試行する」ことのみが記載されており、障害が発生した場合に何が起こるかについての詳細は提供されません. これらの手順に従うとき、応答を受信せずにSTUNトランザクションがタイムアウトした場合、クライアントはRFC 2782で定義された順序で次のサーバーに要求を再試行する必要があります. このような再試行は、要求/応答送信でのみ可能です. 応答もタイムアウトも生成しません.
さらに、デュアルスタックIPv4 / IPv6クライアントは、ドメイン名のAまたはAAAAリソースレコードを照会する代わりに、両方を照会し、[RFC8305]で指定されているように、受信したすべてのIPアドレスで要求を試行しなければなりません.
STUN要求のデフォルトポートは、TCPとUDPの両方で3478です. STUN over TLSおよびSTUN over DTLS要求のデフォルトポートは5349です. サーバーソフトウェアが初期メッセージがDTLSまたはSTUNメッセージであるかどうかの判断をサポートしている場合、サーバーはSTUN over UDPと同じポートでSTUN over DTLSを実行できます. サーバーソフトウェアが初期メッセージがTLSまたはSTUNメッセージであるかどうかの判断をサポートしている場合、サーバーは、STUN over TCPと同じポートでSTUN over TLSを実行できます.
STUNサーバーの管理者は、UDPおよびTCPのSRVレコードでこれらのポートを使用する必要があります. すべての場合において、DNSのポートは、サーバーがリッスンしているポートを反映する必要があります.
SRVレコードが見つからない場合、クライアントは[RFC8305]で説明されているように、ドメイン名のAとAAAAの両方のレコード検索を実行します. その結果、IPアドレスのリストが作成されます. 各IPアドレスは、STUNの使用に関係なく、UDPまたはTCPを使用してデフォルトポートで同時に接続できます. TLSを必要とする使用法では、クライアントはデフォルトのSTUN over TLSポートを使用してIPアドレスに接続します. DTLSを必要とする使用法では、クライアントはデフォルトのSTUN over DTLSポートを使用してIPアドレスに接続します.
9.認証およびメッセージ整合性メカニズム
このセクションでは、クライアントとサーバーが認証とメッセージの整合性を提供するために使用できるSTUNの2つのメカニズムを定義します. これら2つのメカニズムは、short-term credential mechanismとlong-term credential mechanismとして知られています. これら2つのメカニズムはオプションであり、各使用法では、これらのメカニズムを使用するかどうかと使用するタイミングを指定する必要があります. その結果、クライアントとサーバーの両方が、どの使用法が適用されるかに関する知識に基づいて、どのメカニズム（存在する場合）に従うかを認識します. たとえば、ICEをサポートするパブリックインターネット上のSTUNサーバーには認証がありませんが、接続チェックをサポートするエージェントのSTUNサーバー機能は短期間の資格情報を利用します. これら2つのメカニズムの概要は、セクション2に記載されています.
各メカニズムは、そのメカニズムを使用するために必要な追加処理を指定し、セクション6で指定された処理を拡張します. 追加処理は、3つの異なる場所で発生します. メッセージの形成時、エラー応答の詳細な処理.
エージェントは、MESSAGE-INTEGRITY-SHA256およびFINGERPRINT属性を除き、MESSAGE-INTEGRITYに続くすべての属性を無視しなければならないことに注意してください. 同様に、エージェントは、MESSAGE-INTEGRITY属性が存在しない場合、FINGERPRINT属性を除き、MESSAGE-INTEGRITY-SHA256属性に続くすべての属性を無視しなければなりません.
9.1. Short-Term Credential Mechanism
short-term credential mechanismは、STUNトランザクションの前に、クライアントとサーバーが他のプロトコルを使用して、ユーザー名とパスワードの形式でクレデンシャルを交換したことを前提としています. この資格情報には期限があります. 時間制限は使用状況によって定義されます. 例として、ICEの使用法[RFC8445]では、2つのエンドポイントは帯域外シグナリングを使用してユーザー名とパスワードに同意し、このユーザー名とパスワードはメディアセッションの期間中適用されます.
この信任状は、各要求および多くの応答でメッセージの整合性チェックを形成するために使用されます. 長期的なメカニズムのような挑戦と対応はありません. その結果、資格情報の期限が限られているため、再生が制限されます.
9.1.1. HMACキー
Short-Term Credentialの場合、ハッシュベースのメッセージ認証コード（HMAC）キーは次のように定義されます.
key = OpaqueString（password）
OpaqueStringプロファイルは[RFC8265]で定義されています. 使用されるエンコーディングはUTF-8 [RFC3629]です.
9.1.2. リクエストまたは表示の作成
要求または指示メッセージの場合、エージェントは、両方のエージェントがどのメッセージ整合性アルゴリズムをサポートするかを外部メカニズムから知らない限り、メッセージにUSERNAME、MESSAGE-INTEGRITY-SHA256、およびMESSAGE-INTEGRITY属性を含める必要があります. この場合、USERNAMEに加えて、MESSAGE-INTEGRITYまたはMESSAGE-INTEGRITY-SHA256のいずれかを含める必要があります. MESSAGE-INTEGRITY属性のHMACはセクション14.5で説明されているように計算され、MESSAGE-INTEGRITY-SHA256属性のHMACはセクション14.6で説明されているように計算されます. パスワードは要求または指示に含まれないことに注意してください.
9.1.3. リクエストまたは表示の受信
エージェントがメッセージの基本処理を行った後、エージェントは指定された順序で以下にリストされたチェックを実行します.
oメッセージに1）MESSAGE-INTEGRITYまたはMESSAGE-INTEGRITY-SHA256属性と2）USERNAME属性が含まれていない場合：
*メッセージがリクエストの場合、サーバーはリクエストをエラー応答で拒否しなければなりません. この応答では、エラーコード400（Bad Request）を使用する必要があります.
*メッセージが表示の場合、エージェントは表示を静かに破棄する必要があります.
o USERNAMEにサーバー内で現在有効なユーザー名の値が含まれていない場合：
*メッセージがリクエストの場合、サーバーはリクエストをエラー応答で拒否しなければなりません. この応答では、401（認証されていない）のエラーコードを使用する必要があります.
*メッセージが表示の場合、エージェントは表示を静かに破棄する必要があります.
o MESSAGE-INTEGRITY-SHA256属性が存在する場合、セクション14.6で説明されているように、ユーザー名に関連付けられたパスワードを使用して、メッセージの整合性の値を計算します. MESSAGE- INTEGRITY-SHA256属性が存在しない場合、同じパスワードを使用して、セクション14.5で説明されているメッセージの整合性の値を計算します. 結果の値が対応する属性の内容と一致しない場合（MESSAGE-INTEGRITY- SHA256またはMESSAGE-INTEGRITY）：
*メッセージがリクエストの場合、サーバーはリクエストをエラー応答で拒否しなければなりません. この応答では、401（認証されていない）のエラーコードを使用する必要があります.
*メッセージが表示の場合、エージェントは表示を静かに破棄する必要があります.
これらのチェックに合格すると、エージェントはリクエストまたはインジケーションの処理を続けます. MESSAGE-INTEGRITY-SHA256属性を含む要求に対してサーバーが生成する応答には、要求の認証に使用されるパスワードを使用して計算されたMESSAGE-INTEGRITY-SHA256属性を含める必要があります. MESSAGE-INTEGRITY属性のみを含む要求に対してサーバーが生成する応答には、要求の認証に使用されるパスワードを使用して計算されたMESSAGE-INTEGRITY属性を含める必要があります. これは、これらの属性のうち1つのみが応答に表示されることを意味します. 応答にUSERNAME属性を含めることはできません.
チェックのいずれかが失敗した場合、サーバーはエラー応答にMESSAGE-INTEGRITY-SHA256、MESSAGE-INTEGRITY、またはUSERNAME属性を含めてはなりません. これは、これらの障害の場合、サーバーがMESSAGE-INTEGRITY-SHA256またはMESSAGE-INTEGRITY属性を計算するために必要な共有秘密を決定できないためです.
9.1.4. 応答を受け取る
クライアントは、応答でMESSAGE-INTEGRITYまたはMESSAGE-INTEGRITY- SHA256属性を探します. 存在し、クライアントがリクエストでMESSAGE-INTEGRITYまたはMESSAGE-INTEGRITY-SHA256属性のいずれかのみを送信した場合（セクション9.1.2の外部指示のため、またはセクション9.1.5で定義されている後続のリクエストのため） 、応答のアルゴリズムは一致する必要があります. それ以外の場合、応答は破棄する必要があります.
次に、クライアントは、リクエストに使用したのと同じパスワードを使用して、MESSAGE-INTEGRITY属性のセクション14.5またはMESSAGE-INTEGRITY-SHA256属性のセクション14.6で定義されているように、応答のメッセージ整合性を計算します. 結果の値がそれぞれMESSAGE-INTEGRITYまたはMESSAGE-INTEGRITY-SHA256属性の内容と一致する場合、応答は認証されたと見なされます. 値が一致しない場合、またはMESSAGE-INTEGRITYとMESSAGE-INTEGRITY-SHA256の両方が存在しない場合、処理は信頼できるトランスポートで送信されたか、信頼性の低いトランスポートで送信されたかによって異なります.
要求が信頼できないトランスポートを介して送信された場合、応答は受信されなかったかのように破棄されなければなりません. これは、該当する場合、再送信が続行されることを意味します. 受信したすべての応答が破棄された場合、トランザクションの終了後にタイムアウトを通知する代わりに、層は整合性保護が違反されたことを通知する必要があります.
要求が信頼できるトランスポートを介して送信された場合、応答は破棄されなければならず、レイヤーはトランザクションを直ちに終了し、整合性保護が違反されたことを通知しなければなりません.
9.1.5. 後続のリクエストを送信する
同じサーバーに後続のリクエストを送信するクライアントは、最初のリクエストへの応答で受信した属性に一致するMESSAGE-INTEGRITY-SHA256またはMESSAGE-INTEGRITY属性のみを送信する必要があります. ここで、「同じサーバー」とは、同じURIまたはSRVルックアップ結果だけでなく、同じIPアドレスとポート番号を意味します.
9.2. long-term credential mechanism
long-term credential mechanismは、クライアントとサーバー間で共有されるユーザー名とパスワードの形式のLong-Term Credentialに依存しています. 資格情報はユーザー用にプロビジョニングされ、ユーザーがシステムのサブスクライバーでなくなるか、変更されるまで有効であると想定されるため、長期と見なされます. これは基本的に、ユーザーに与えられる従来の「ログイン」ユーザー名とパスワードです.
これらのユーザー名とパスワードは長期間有効であると予想されるため、リプレイ防止はダイジェストチャレンジの形式で提供されます. このメカニズムでは、クライアントは最初に要求を送信しますが、資格情報や整合性チェックは提供しません. サーバーはこの要求を拒否し、ユーザーにレルム（ユーザーまたはエージェントがユーザー名とパスワードを選択する際のガイドに使用）とノンスを提供します. ノンスは、制限されたリプレイ保護を提供します. これは、サーバーによって選択され、有効期間または有効なクライアントIDを示すようにエンコードされたCookieです. サーバーのみがCookieの内部構造を知る必要があります. クライアントはリクエストを再試行しますが、今回はユーザー名とレルムを含め、サーバーから提供されたナンスをエコーし​​ます. クライアントには、このドキュメントで定義されているメッセージ整合性属性の1つも含まれています. この属性は、ノンスを含むリクエスト全体にHMACを提供します. サーバーはナンスを検証し、メッセージの整合性をチェックします. 一致する場合、要求は認証されます. ナンスが有効でなくなった場合は「古い」と見なされ、サーバーはリクエストを拒否して新しいナンスを提供します.
同じサーバーへの後続のリクエストでは、クライアントは以前に使用したナンス、ユーザー名、レルム、パスワードを再利用します. この方法では、後続のリクエストは、サーバーによってナンスが無効になるまで拒否されません. その場合、拒否はクライアントに新しいノンスを提供します.
インジケーションはチャレンジできないため、長期クレデンシャルメカニズムを使用してインジケーションを保護できないことに注意してください. インジケーションを使用する使用法では、短期間の資格情報を使用するか、それらの認証とメッセージの整合性を省略する必要があります.
この仕様をサポートすることを示すために、サーバーは、セクションで定義されているように、24ビットSTUNセキュリティ機能の（4文字）base64 [RFC4648]エンコードと連結した「obMatJos2」で構成される文字列をNONCE属性値の先頭に追加する必要があります18.1. 24ビットのセキュリティ機能セットは3バイトとしてエンコードされ、ビット0が最初のバイトの最上位ビットであり、ビット23が3番目のバイトの最下位ビットです. セキュリティ機能を使用しない場合、代わりに24ビットすべてがゼロに設定されたバイト配列をエンコードする必要があります. このドキュメントの残りの部分では、「nonce cookie」という用語は、NONCE属性値の前に追加される完全な13文字の文字列を指します.
long-term credential mechanismはオフライン辞書攻撃の影響を受けやすいため、展開では推測が困難なパスワードを使用する必要があります. 資格情報がユーザーによって入力されず、デバイスのプロビジョニング中にクライアントデバイスに配置される場合、パスワードは少なくとも128ビットのランダム性を持つ必要があります. ユーザーが資格情報を入力する場合、パスワード構造に関する現在のベストプラクティスに従う必要があります.
9.2.1. 入札攻撃の防止
このドキュメントでは、パスワード保護に使用するアルゴリズムを選択する機能と匿名ユーザー名を使用する機能を提供する2つの新しいセキュリティ機能を紹介します. これらの機能は両方とも、STUNプロトコルの以前のバージョンとの下位互換性を保つためにオプションです.
これらの新しい機能は、メッセージパスの攻撃者がこれらの機能を削除し、より弱いセキュリティプロパティを強制することができる、値引き攻撃の対象となります. この種の攻撃が検出されないようにするために、ノンスは追加情報で強化されています.
「nonce cookie」の値は、選択された特定のSTUNセキュリティ機能ビットによって異なります. このドキュメントが特定のSTUNセキュリティ機能について議論しているセクションで「ノンスクッキー」を参照するとき、「ノンスクッキー」の対応するSTUNセキュリティ機能ビットが1に設定されると理解されます.
たとえば、PASSWORD-ALGORITHMSセキュリティ機能（セクション9.2.4で定義）を使用すると、対応する「パスワードアルゴリズム」ビット（セクション18.1で定義）が「nonce cookie」で1に設定されます.
9.2.2. HMACキー
PASSWORD-ALGORITHM属性で指定されている、異なるアルゴリズムを使用しないLong-Term Credentialの場合、キーは16バイトです.
key = MD5（username "：" OpaqueString（realm） "：" OpaqueString（password））
MD5は[RFC1321]および[RFC6151]で定義されており、OpaqueStringプロファイルは[RFC8265]で定義されています. 使用されるエンコーディングはUTF-8 [RFC3629]です.
16バイトのキーは、次の5つのフィールドを連結した結果のMD5ハッシュを取得することで形成されます. （1）USERNAME属性から取得された引用符と末尾のヌルが削除されたユーザー名（この場合、OpaqueStringは既に適用）; （2）単一のコロン. （3）引用符と末尾のヌルが削除され、OpaqueStringを使用して処理された後のレルム. （4）単一のコロン. （5）パスワード. 末尾のヌルが削除され、OpaqueStringを使用して処理された後. たとえば、ユーザー名が「user」、レルムが「realm」、パスワードが「pass」の場合、16バイトのHMACキーは、ストリング「user：realm」でMD5ハッシュを実行した結果になります. 結果として得られるハッシュは0x8493fbc53ba582fb4c044c456bdc40ebです.
キーの構造は、Long-Term Credentialとともに使用される場合、SIP [RFC3261]も利用するシステムでの展開を容易にします. 通常、SIPのダイジェスト認証メカニズムを利用するSIPシステムは、実際にはデータベースにパスワードを保存しません. むしろ、上記で定義したキーに等しい「H（A1）」という値を保存します. たとえば、このメカニズムは、[RFC5090]で定義されている認証拡張機能で使用できます.
PASSWORD-ALGORITHMを使用する場合、使用するキーの長さとアルゴリズムについては、セクション18.5.1で説明しています.
9.2.3. リクエストの作成
クライアントからサーバーへの最初の要求（セクション8のDNS手順が使用されている場合はホスト名で、使用されていない場合はIPアドレスで識別される）は、セクション9.2.3.1のルールに従って処理されます. 前の要求/応答トランザクションが正常に完了した後、クライアントが後続の要求を開始すると、9.2.3.2項の規則に従います. 401（未認証）または438（古いノンス）エラー応答の結果としてリクエストを形成することは、セクション9.2.5で扱われ、「後続のリクエスト」とは見なされないため、セクション9.2.3.2で説明されているルールを利用しません. これらのタイプのリクエストにはそれぞれ、異なる必須属性があります.
9.2.3.1. 最初のリクエスト
クライアントがサーバーとの正常な要求/応答トランザクションを完了していない場合、USERNAME、USERHASH、MESSAGE-INTEGRITY、MESSAGE-INTEGRITY-SHA256、REALM、NONCE、PASSWORD- ALGORITHMS、およびPASSWORD-ALGORITHM属性を省略しなければなりません. つまり、最初の要求は、認証またはメッセージ整合性が適用されていないかのように送信されます.
9.2.3.2. 後続のリクエスト
要求/応答トランザクションが完了すると、クライアントはサーバーによってレルムとノンスを提示され、認証に使用したユーザー名とパスワードを選択します. クライアントは、その後のサーバーとの通信のために、ユーザー名、パスワード、レルム、ノンスをキャッシュする必要があります. クライアントが後続のリクエストを送信する場合、USERNAMEまたはUSERHASH、REALM、NONCE、およびPASSWORD-ALGORITHM属性のいずれかとこれらのキャッシュされた値を含める必要があります. キャッシュされたパスワードを使用してセクション14.5および14.6で説明されているように計算されたMESSAGE-INTEGRITY属性またはMESSAGE-INTEGRITY-SHA256属性を含まなければなりません. 2つの属性間の選択は、最初の要求への応答で受信した属性によって異なります.
9.2.4. リクエストを受け取る
サーバーはリクエストの基本処理を行った後、指定された順序で以下にリストされたチェックを実行します. REALM値は、STUNサーバーのプロバイダーのドメイン名であることが推奨されることに注意してください.
oメッセージにMESSAGE-INTEGRITYまたはMESSAGE-INTEGRITY-SHA256属性が含まれていない場合、サーバーはエラーコード401（認証されていない）でエラー応答を生成しなければなりません. この応答には、REALM値を含める必要があります. 応答には、サーバーが選択したNONCEを含める必要があります. サーバーは、送信元IPアドレスとポートが同じでない限り、2つの要求に同じNONCEを選択してはなりません. サーバーは代替パスワードアルゴリズムをサポートする場合があります. その場合、PASSWORD-ALGORITHMS属性に優先的な順序でそれらをリストできます. サーバーがPASSWORD-ALGORITHMS属性を追加する場合、STUNセキュリティ機能の「パスワードアルゴリズム」ビットを1に設定する必要があります. サーバーは匿名ユーザー名をサポートする場合があります. その場合、STUNセキュリティ機能の「ユーザー名匿名」ビットを1に設定する必要があります.
注：さまざまなソースIPアドレスまたはポートにNONCEを再利用することは、[RFC5389]で明示的に禁止されていません.
oメッセージにMESSAGE-INTEGRITYまたはMESSAGE-INTEGRITY-SHA256属性が含まれているが、USERNAMEまたはUSERHASH、REALM、またはNONCE属性のいずれかが欠落している場合、サーバーはエラーコード400（不正な要求）でエラー応答を生成する必要があります. この応答には、USERNAME、USERHASH、NONCE、またはREALMを含めないでください.
属性. 応答にMESSAGE-INTEGRITYまたはMESSAGE-INTEGRITY-SHA256属性を含めることはできません. これらの属性を生成するために必要な属性が欠落しているためです.
o NONCE属性が「nonce cookie」で始まり、STUNセキュリティ機能の「パスワードアルゴリズム」ビットが1に設定されている場合、サーバーは指定された順序でこれらのチェックを実行します.
*要求にPASSWORD-ALGORITHMSアルゴリズムもPASSWORD-ALGORITHMアルゴリズムも含まれていない場合、要求はPASSWORD-ALGORITHMがMD5であるかのように処理されます.
*それ以外の場合は、（1）PASSWORD-ALGORITHMとPASSWORD- ALGORITHMSの両方が存在し、（2）PASSWORD-ALGORITHMSはこのNONCEを送信した応答で送信された値と一致し、（3）PASSWORD-ALGORITHMはPASSWORDのエントリの1つと一致します-ALGORITHMS、サーバーはエラーコード400（Bad Request）でエラー応答を生成しなければなりません.
o USERNAMEまたはUSERHASH属性の値が有効でない場合、サーバーはエラーコード401（認証されていない）でエラー応答を生成しなければなりません. この応答には、REALM値を含める必要があります. 応答には、サーバーが選択したNONCEを含める必要があります. 応答には、PASSWORD-ALGORITHMS属性を含める必要があります. 応答には、USERNAMEまたはUSERHASH属性を含めるべきではありません. 応答には、前のキーを使用して計算するMESSAGE-INTEGRITYまたはMESSAGE-INTEGRITY-SHA256属性を含めることができます.
o MESSAGE-INTEGRITY-SHA256属性が存在する場合、セクション14.6で説明されているように、ユーザー名に関連付けられたパスワードを使用して、メッセージの整合性の値を計算します. それ以外の場合、同じパスワードを使用して、セクション14.5の説明に従ってMESSAGE-INTEGRITY属性の値を計算します. 結果の値がMESSAGE-INTEGRITY属性またはMESSAGE-INTEGRITY-SHA256属性の内容と一致しない場合、サーバーはエラー応答で要求を拒否しなければなりません. この応答では、401（認証されていない）のエラーコードを使用する必要があります. REALM属性とNONCE属性を含める必要があり、USERNAME、USERHASH、MESSAGE-INTEGRITY、またはMESSAGE-INTEGRITY-SHA256属性を含めるべきではありません.
o NONCEがもはや有効でない場合、サーバーはエラーコード438（Stale Nonce）でエラー応答を生成しなければなりません. この応答には、NONCE、REALM、およびPASSWORD-ALGORITHMS属性を含める必要があり、USERNAME属性とUSERHASH属性を含めるべきではありません. NONCE属性値は有効でなければなりません. 応答には、MESSAGE-INTEGRITYまたはMESSAGE-INTEGRITY-SHA256属性を含めることができます.
計算する前のNONCE. サーバーは、追加のセキュリティを提供するためにノンスを取り消すことができます. ガイドラインについては、[RFC7616]のセクション5.4を参照してください.
これらのチェックに合格すると、サーバーはリクエストの処理を続行します. PASSWORD-ALGORITHMがMD5であるかのようにリクエストが処理されない限り、リクエストはPASSWORD-ALGORITHMSも含まれていなかったため、サーバーによって生成された応答には、リクエストの認証に使用されるユーザー名とパスワードを使用して計算されたMESSAGE-INTEGRITY-SHA256属性が含まれなければなりませんPASSWORD-ALGORITHM）. その場合、MESSAGE-INTEGRITY-SHA256属性の代わりにMESSAGE-INTEGRITY属性を使用しなければならず、REALM、NONCE、USERNAME、およびUSERHASH属性は含まれるべきではない（SHOULD NOT）.
9.2.5. 応答を受け取る
応答が401（認証されていない）または438（古いNonce）のエラーコードを持つエラー応答である場合、クライアントはNONCE属性値が「nonce cookie」で始まるかどうかをテストする必要があります. その場合、「ノンスCookie」のSTUNセキュリティ機能「パスワードアルゴリズム」ビットが1に設定されているが、PASSWORD-ALGORITHMS属性が存在しない場合、クライアントは新しいトランザクションでリクエストを再試行してはならない.
応答がエラーコード401（認証なし）のエラー応答である場合、クライアントは新しいトランザクションで要求を再試行する必要があります. この要求には、エラー応答からのREALMの適切なユーザー名としてクライアントが決定したUSERNAMEまたはUSERHASHが含まれている必要があります. 「nonce cookie」が存在し、STUN Security Featureの「Username anonymity」ビットが1に設定されている場合、USERHASH属性を使用する必要があります. それ以外の場合、USERNAME属性を使用する必要があります. 要求には、エラー応答からコピーされたREALMを含める必要があります. 要求には、エラー応答からコピーされたNONCEを含める必要があります. 応答にPASSWORD-ALGORITHMS属性が含まれる場合、要求には同じ内容のPASSWORD-ALGORITHMS属性が含まれなければなりません. 応答にPASSWORD-ALGORITHMS属性が含まれる場合、そして、この属性はクライアントによってサポートされる少なくとも1つのアルゴリズムを含みます、そして、要求はリストでサポートされる最初のアルゴリズムでPASSWORD- ALGORITHM属性を含まなければなりません. 応答にPASSWORD-ALGORITHMS属性が含まれ、この属性にクライアントがサポートするアルゴリズムが含まれていない場合、クライアントは新しいトランザクションで要求を再試行してはなりません. クライアントは、前回の試行からUSERNAME、USERHASH、REALM、またはその関連パスワードを変更していない場合、この再試行を実行してはなりません. その後、クライアントは新しいトランザクションでリクエストを再試行してはなりません. クライアントは、前回の試行からUSERNAME、USERHASH、REALM、またはその関連パスワードを変更していない場合、この再試行を実行してはなりません. その後、クライアントは新しいトランザクションでリクエストを再試行してはなりません. クライアントは、前回の試行からUSERNAME、USERHASH、REALM、またはその関連パスワードを変更していない場合、この再試行を実行してはなりません.
応答がエラーコード438（Stale Nonce）のエラー応答である場合、クライアントは438（Stale Nonce）応答で提供された新しいNONCE属性を使用して、要求を再試行する必要があります. この再試行には、USERNAMEまたはUSERHASH、REALM、およびMESSAGE-INTEGRITYまたはMESSAGE-INTEGRITY-SHA256属性のいずれかを含める必要があります.
他のすべての応答については、NONCE属性が「nonce cookie」で始まり、STUNセキュリティ機能の「パスワードアルゴリズム」ビットが1に設定されているが、PASSWORD-ALGORITHMSが存在しない場合、応答を無視する必要があります.
応答がエラーコード400（Bad Request）のエラー応答であり、MESSAGE-INTEGRITYまたはMESSAGE-INTEGRITY-SHA256属性のいずれも含まれていない場合、応答は受信されなかったかのように破棄されなければなりません（MUST）. これは、該当する場合、再送信が続行されることを意味します.
注：この場合、400応答はアプリケーションに到達しないため、タイムアウトになります.
クライアントは、応答（成功または失敗のいずれか）でMESSAGE-INTEGRITYまたはMESSAGE-INTEGRITY- SHA256属性を探します. 存在する場合、クライアントは、セクション14.5または14.6で定義されているように、要求に対して使用したのと同じパスワードを使用して、応答に対するメッセージの整合性を計算します. 結果の値がMESSAGE-INTEGRITYまたはMESSAGE-INTEGRITY-SHA256属性の内容と一致する場合、応答は認証済みと見なされます. 値が一致しない場合、またはMESSAGE-INTEGRITYとMESSAGE-INTEGRITY-SHA256の両方が存在しない場合、処理は信頼できるトランスポートまたは信頼できないトランスポートを介して送信される要求に依存します.
要求が信頼できないトランスポートを介して送信された場合、応答は受信されなかったかのように破棄されなければなりません. これは、該当する場合、再送信が続行されることを意味します. 受信したすべての応答が破棄された場合、トランザクションの終了後にタイムアウトを通知する代わりに、層は整合性保護が違反されたことを通知する必要があります.
要求が信頼できるトランスポートを介して送信された場合、応答は破棄されなければならず、レイヤーはトランザクションを直ちに終了し、整合性保護が違反されたことを通知しなければなりません.
応答にPASSWORD-ALGORITHMS属性が含まれる場合、MESSAGE-INTEGRITY-SHA256のみを使用して、後続のすべての要求を認証する必要があります.
10. ALTERNATE-SERVERメカニズム
このセクションでは、サーバーがクライアントを別のサーバーにリダイレクトできるようにするSTUNのメカニズムについて説明します. この拡張機能はオプションであり、使用法は、この拡張機能を使用するかどうかと使用するタイミングを定義する必要があります. ALTERNATE-SERVER属性には、IPアドレスが含まれています.
この拡張機能を使用するサーバーは、エラーコード300（代替試行）のエラー応答メッセージで要求メッセージに応答することにより、クライアントを別のサーバーにリダイレクトします. サーバーは、エラー応答に少なくとも1つのALTERNATE-SERVER属性を含める必要があります. これには、要求メッセージのソースIPアドレスと同じアドレスファミリのIPアドレスが含まれている必要があります. サーバーは、必須メッセージの後に、リクエストメッセージのソースIPアドレス以外のアドレスファミリのIPアドレスを含む追加のALTERNATE-SERVER属性を含める必要があります. エラー応答メッセージが認証される場合があります. ただし、応答の認証が不可能または実用的ではないALTERNATE-SERVERの使用例があります. トランザクションがTLSまたはDTLSを使用する場合、トランザクションがMESSAGE-INTEGRITY-SHA256属性によって認証される場合、サーバーが別の証明書を使用するサーバーにリダイレクトする場合は、その証明書のsubjectAltName内に名前を含むALTERNATE-DOMAIN属性を含める必要があります. MESSAGE-INTEGRITY-SHA256属性に関するこの一連の条件は、トランザクションが認証され、クライアントがこの仕様を実装しているため、ALTERNATE-DOMAIN属性を処理できることを示しています.
この拡張機能を使用するクライアントは、300（代替を試行）エラーコードを次のように処理します. クライアントは、エラー応答でALTERNATE-SERVER属性を探します. 見つかった場合、クライアントは現在のトランザクションが失敗したと見なし、以前のリクエストで使用したものと同じトランスポートプロトコルを使用して、属性で指定されたサーバーでリクエストを再試行します. その要求は、認証された場合、リダイレクトを実行したサーバーへの要求でクライアントが使用したのと同じ資格情報を利用しなければなりません. トランスポートプロトコルがTLSまたはDTLSを使用する場合、クライアントはALTERNATE-DOMAIN属性を探します. 属性が見つかった場合、ドメインを使用して、[RFC6125]の推奨事項を使用して証明書を検証する必要があります. 証明書には、タイプSRV-IDまたはURI-IDではなく、タイプDNS-IDまたはCN-ID（最終的にはワイルドカードを含む）の識別子を含める必要があります. 属性が見つからない場合は、元の要求に使用されたのと同じドメインを使用して証明書を検証する必要があります. クライアントが過去5分以内にこの要求を既に送信したサーバーにリダイレクトされた場合、リダイレクトを無視し、トランザクションが失敗したと見なさなければなりません. これにより、リダイレクトループの場合にサーバー間の無限のpingポンギングが防止されます. 11. RFC 3489との後方互換性 リダイレクトを無視し、トランザクションが失敗したと見なさなければなりません. これにより、リダイレクトループの場合にサーバー間の無限のpingポンギングが防止されます. 11. RFC 3489との後方互換性 リダイレクトを無視し、トランザクションが失敗したと見なさなければなりません. これにより、リダイレクトループの場合にサーバー間の無限のpingポンギングが防止されます. 11. RFC 3489との後方互換性
[RFC5389]のセクション12ですでに説明されている後方互換性に加えて、[RFC3489]（「クラシックSTUN」と呼ばれる）でDTLSを使用してはなりません（MUST NOT）. DTLSを介したマジックCookie（[RFC5389]のセクション6を参照）のないSTUNリクエストまたは表示は無効と見なされなければなりません：すべてのリクエストは500（サーバーエラー）エラー応答を生成しなければならず、表示は無視されなければなりません.
12.基本的なサーバーの動作
このセクションでは、基本的なスタンドアロンSTUNサーバーの動作を定義します.
歴史的に、「クラシックSTUN」[RFC3489]は、STUNバインディング要求を受信して​​応答することにより、クライアントにサーバーreflexive transport addressを提供していたサーバーの動作のみを定義していました. [RFC5389]プロトコルを拡張可能なフレームワークとして再定義し、サーバー機能がそのドキュメントで定義されている唯一のSTUN Usageになりました. このSTUNの使用法は、「基本STUNサーバー」とも呼ばれます.
STUNサーバーはBindingメソッドをサポートする必要があります. 短期または長期のクレデンシャルメカニズムを使用しないでください. これは、要求の認証に関係する作業が、単純に処理するだけの作業ではないためです. 同じ理由で、ALTERNATE-SERVERメカニズムを利用すべきではありません. UDPおよびTCPをサポートする必要があります. TCP / TLS上のSTUNまたはUDP / DTLS上のSTUNをサポートする場合があります. ただし、DTLSとTLSは、この基本的な動作モードで最小限のセキュリティ上の利点を提供します. TCPまたはTLS-over-TCP接続はバインディングトランザクションの終了後に閉じられるため、キープアライブメカニズムは必要ありません. FINGERPRINTメカニズムを利用できますが、必須ではありません. スタンドアロンサーバーはSTUNのみを実行するため、FINGERPRINTは利点を提供しません. それを要求すると、RFC 3489との互換性が失われます. また、このような互換性はスタンドアロンサーバーで望ましいものです. スタンドアロンSTUNサーバーは、セクション11で説明されているように、[RFC3489]を使用するクライアントとの後方互換性をサポートする必要があります.
セクション8で説明されているように、STUNサーバーの管理者がそれらのサーバーのDNSエントリを提供することが推奨されます. AとAAAAリソースレコードの両方が返される場合、クライアントは同時にIPv4およびIPv6アドレス（[ RFC8305]）、バインディングリクエストがべき等であるため. 返されるMAPPED-ADDRESSまたはXOR-MAPPED-ADDRESS属性は、使用されるサーバーアドレスのアドレスファミリと必ずしも一致しないことに注意してください.
基本的なSTUNサーバーは、NATトラバーサル自体のソリューションではありません. ただし、STUN Usagesを通じてソリューションの一部として利用できます. これについては、セクション13でさらに説明します.
13. STUNの使用法
STUN自体は、NATトラバーサル問題の解決策ではありません. むしろ、STUNは、より大きなソリューション内で使用できるツールを定義しています. 「STUNの使用法」という用語は、STUNをコンポーネントとして使用するソリューションに使用されます.
STUN Usageは、STUNが実際にどのように利用されるかを定義します-リクエストを送信するタイミング、レスポンスをどう処理するか、そしてここ（またはSTUNの拡張で）で定義されるオプションのプロシージャが使用されるべきです 使用法では以下も定義します.
o使用されているSTUNメソッド.
o使用されるトランスポート. DTLS-over-UDPが使用される場合、[RFC6347]のセクション4.2.1で説明されているDoS対策の実装は必須です.
o使用される認証およびメッセージ整合性メカニズム.
o [RFC4107]で説明されているように、整合性メカニズムの手動と自動のキー派生に関する考慮事項.
o STUNメッセージを他のメッセージと区別するために使用されるメカニズム. STUNがTCPまたはTLS-over-TCPで実行される場合、フレーミングメカニズムが必要になる場合があります.
o STUNクライアントがSTUNサーバーのIPアドレスとポートを決定する方法.
o両方のアドレスファミリがSTUNサーバーで見つかった場合、IPv4アドレスとIPv6アドレス（Happy Eyeballs [RFC8305]）の同時使用が非べき等トランザクションでどのように機能するか.
o RFC 3489への後方互換性が必要かどうか.
oここで（FINGERPRINTやALTERNATE-SERVERなど）、または他の拡張機能で定義されているオプションの属性が必要です.
o MESSAGE-INTEGRITY-SHA256切り捨てが許可されている場合、および切り捨てに許可されている制限.
o STUNがTCPまたはTLS-over-TCPで実行される場合のキープアライブメカニズム.
o 1）TCPまたはTLS-over-TCP、または2）認証が使用されている場合に、サーバーにエニーキャストアドレスを使用できる場合.
さらに、STUNの使用では、その使用でSTUNを使用することのセキュリティへの影響を考慮する必要があります. STUNに対する多くの攻撃が知られており（このドキュメントの「セキュリティに関する考慮事項」セクションを参照）、どのような使用法でもこれらの攻撃を阻止または軽減する方法を考慮する必要があります.
最後に、STUNの使用がNATトラバーサルに対する一方的な自己アドレス修正アプローチの例であるかどうかを検討し、もしそうなら、RFC 3424 [RFC3424]で提起された質問に対処する必要があります.
14. STUN Attributes STUN属性
STUNヘッダーの後には、0個以上の属性があります. 各属性は、16ビットタイプ、16ビット長、および値でTLVエンコードする必要があります. 各STUN属性は、32ビット境界で終了する必要があります. 前述のように、属性内のすべてのフィールドは、最上位ビットが最初に送信されます.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (variable) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Format of STUN Attributes
Lengthフィールドの値には、パディング前の属性のValue部分の長さがバイト単位で含まれていなければなりません. STUNは属性を32ビット境界で整列させるため、内容が4バイトの倍数ではない属性は、その値に4バイトの倍数が含まれるように1、2、または3バイトのパディングでパディングされます. パディングビットは送信時にゼロに設定する必要があり、受信者は無視する必要があります.
属性タイプは、STUNメッセージに複数回現れる場合があります. 特に指定しない限り、出現の順序は重要です. 最初の出現のみが受信者によって処理される必要があり、重複は受信者によって無視される場合があります.
この仕様の将来の改訂で必要に応じて新しい属性を追加できるように、属性スペースは2つの範囲に分割されています. タイプ値が0x0000〜0x7FFFの属性は理解が必要な属性です. つまり、STUNエージェントは、属性を理解しない限りメッセージを正常に処理できません. タイプ値が0x8000〜0xFFFFの属性は理解オプションの属性です. つまり、STUNエージェントが理解できない場合、それらの属性は無視できます.
STUN属性タイプのセットは、IANAによって維持されます. この仕様で定義されている初期セットは、セクション18.3にあります.
このセクションの残りの部分では、この仕様で定義されているさまざまな属性の形式について説明します.
14.1. マップされたアドレス
MAPPED-ADDRESS属性は、クライアントのreflexive transport addressを示します. これは、8ビットアドレスファミリと16ビットポートで構成され、その後にIPアドレスを表す固定長の値が続きます. アドレスファミリがIPv4である場合、アドレスは32ビットでなければなりません. アドレスファミリがIPv6の場合、アドレスは128ビットでなければなりません. すべてのフィールドはネットワークバイト順である必要があります.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Family | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address (32 bits or 128 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Format of MAPPED-ADDRESS Attribute
アドレスファミリは、次の値を取ることができます.
0x01：IPv4 0x02：IPv6
MAPPED-ADDRESSの最初の8ビットは0に設定されなければならず、受信者は無視しなければなりません. これらのビットは、自然な32ビット境界でパラメーターを調整するために存在します.
この属性は、[RFC3489]クライアントとの後方互換性を実現するためにサーバーでのみ使用されます.
14.2. XOR-MAPPED-ADDRESS
XOR-MAPPED-ADDRESS属性は、反射トランスポートアドレスがXOR関数によって難読化されることを除いて、MAPPED-ADDRESS属性と同じです.
XOR-MAPPED-ADDRESSの形式は次のとおりです.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Family | X-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| X-Address (Variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Format of XOR-MAPPED-ADDRESS Attribute
FamilyフィールドはIPアドレスファミリを表し、MAPPED-ADDRESSのFamilyフィールドと同じようにエンコードされます.
X-Portは、マップされたポートとマジックCookieの最上位16ビットとのXOR演算によって計算されます. IPアドレスファミリがIPv4の場合、X-Addressは、マッピングされたIPアドレスとマジックCookieのXOR演算によって計算されます. IPアドレスファミリがIPv6の場合、X-Addressは、マッピングされたIPアドレスとマジッククッキーと96ビットトランザクションIDの連結とのXOR演算によって計算されます. すべての場合において、XOR操作はネットワークバイト順（つまり、メッセージでエンコードされる順序）で入力に対して機能します.
属性値の最初の8ビットをエンコードおよび処理するための規則、属性の複数のオカレンスを処理するための規則、およびアドレスファミリを処理するための規則は、MAPPED-ADDRESSの場合と同じです.
注：XOR-MAPPED-ADDRESSとMAPPED-ADDRESSは、トランスポートアドレスのエンコードのみが異なります. 前者は、トランスポートアドレスをマジックCookieとXORすることによりエンコードします. 後者は、バイナリで直接エンコードします. RFC 3489は元々、MAPPED-ADDRESSのみを指定していました. ただし、展開の経験から、一部のNATは、STUNのMAPPED-ADDRESS属性など、NATのパブリックIPアドレスを含む32ビットバイナリペイロードを書き換えますが、一般的なアプリケーションレイヤーゲートウェイ（ALG）機能を提供するという意味のある誤った試みです. このような動作は、STUNの動作を妨害し、STUNのメッセージ整合性チェックの失敗も引き起こします.
14.3. USERNAME
USERNAME属性は、メッセージの整合性のために使用されます. メッセージの整合性チェックで使用されるユーザー名とパスワードの組み合わせを識別します.
USERNAMEの値は、認証ユーザー名を含む可変長の値です. 509バイト未満のUTF-8エンコード[RFC3629]シーケンスを含まなければならず、OpaqueStringプロファイル[RFC8265]を使用して処理されている必要があります. 準拠する実装は、[RFC5389]と互換性があるために、763以下のUTF-8エンコードシーケンスを解析できる必要があります.
注：[RFC5389]は[RFC2279]のUTF-8の定義を誤って参照しました. [RFC2279]は、エンコードされた文字ごとに最大6オクテットを想定しています. [RFC2279]は[RFC3629]に置き換えられました. これは、エンコードされた文字ごとに4オクテットのみを許可し、Unicode 2.0およびISO / IEC 10646で行われた変更と一致します.
注：この仕様では、展開されたパスワードストアとの互換性を向上させるために、ユーザー名文字列処理にUsernameCasePreservedプロファイルの代わりにOpaqueStringプロファイルを使用します. HTTPおよびSIPダイジェスト認証に使用される多くのパスワードデータベースは、プレーンテキストパスワードを保存する代わりに、username：realm：passwordのMD5ハッシュを保存します. [RFC3489]では、STUN認証は、これらの既存のデータベースと可能な範囲で互換性があるように設計されました. SIPやHTTPは、非スペースASCII制御文字を禁止する以外のユーザー名とパスワードの前処理を実行しませんでした. STUN仕様の次の改訂版[RFC5389]は、SASLprep [RFC4013] stringprep [RFC3454]プロファイルを使用してユーザー名とパスワードを前処理しました. SASLprepは、Unicode Normalization Form KC（互換性分解、その後にCanonical Composition）[UAX15]があり、さまざまな制御、スペース、非テキスト、非推奨、または不適切なコードポイントが禁止されています. PRECISフレームワーク[RFC8264]はstringprepを廃止します. PRECISによるユーザー名とパスワードの処理[RFC8265]は、Unicode正規化フォームC（正規分解、それに続く正規合成）を使用します. HTTPダイジェストの異なるユーザー名文字列をOpaqueStringで処理された単一のSTUNユーザー名にマッピングできる特定のケースがありますが、これらのケースは非常にまれで、検出および修正が容易です. UsernameCasePreservedプロファイルを使用すると、HTTPダイジェストで有効なユーザー名が処理済みのフォーム（特に双方向テキストと互換性フォームを含むユーザー名）と一致しない可能性が高くなります.
14.4. USERHASH
USERHASH属性は、ユーザー名の匿名性がサポートされている場合、USERNAME属性の代わりとして使用されます.
USERHASHの値は、32バイトの固定長です. ユーザー名はOpaqueStringプロファイル[RFC8265]を使用して処理されている必要があり、レルムはハッシュする前にOpaqueStringプロファイル[RFC8265]を使用して処理されている必要があります.
以下は、クライアントがユーザー名をハッシュするために実行する操作です.
userhash = SHA-256（OpaqueString（username） "：" OpaqueString（realm））
14.5. メッセージの完全性
MESSAGE-INTEGRITY属性には、STUNメッセージのHMAC-SHA1 [RFC2104]が含まれています. MESSAGE-INTEGRITY属性は、任意のSTUNメッセージタイプに存在できます. SHA-1ハッシュを使用するため、HMACは20バイトになります.
HMACのキーは、使用されている資格情報メカニズムによって異なります. セクション9.1.1は、短期間の資格情報メカニズムのキーを定義し、セクション9.2.2は、長期的な資格情報メカニズムのキーを定義します. 他のクレデンシャルメカニズムは、HMACに使用されるキーを定義する必要があります.
HMACへの入力として使用されるテキストは、MESSAGE-INTEGRITY属性に先行する属性までのSTUNメッセージです. STUNメッセージヘッダーの長さフィールドは、MESSAGE-INTEGRITY属性の終わりを指すように調整されます. MESSAGE-INTEGRITY属性の値は、ダミー値に設定されます.
計算が実行されると、MESSAGE-INTEGRITY属性の値が入力され、STUNヘッダーの長さの値が正しい値（メッセージ全体の長さ）に設定されます. 同様に、MESSAGE-INTEGRITYを検証する場合、STUNヘッダーのLengthフィールドは、MESSAGE-の前の属性までのSTUNメッセージでHMACを計算する前に、MESSAGE-INTEGRITY属性の終わりを指すように調整する必要がありますINTEGRITY属性. このような調整は、FINGERPRINTやMESSAGE-INTEGRITY-SHA256などの属性がMESSAGE-INTEGRITYの後に表示される場合に必要です. そのような計算の例については、[RFC5769]も参照してください.
14.6. メッセージ-完全性-SHA256
MESSAGE-INTEGRITY-SHA256属性には、STUNメッセージのHMAC-SHA256 [RFC2104]が含まれています. MESSAGE-INTEGRITY-SHA256属性は、任意のSTUNメッセージタイプに存在できます. MESSAGE-INTEGRITY-SHA256属性には、STUNメッセージのHMAC-SHA-256 [RFC2104]の初期部分が含まれています. 値は最大32バイトですが、少なくとも16バイトでなければならず、4バイトの倍数でなければなりません. STUN Usageで切り捨てが許可されていることが明示的に指定されていない限り、値は完全な32バイトでなければなりません. STUNの用途では、16バイトより長い最小長を指定できます.
HMACのキーは、使用されている資格情報メカニズムによって異なります. セクション9.1.1は、短期間の資格情報メカニズムのキーを定義し、セクション9.2.2は、長期的な資格情報メカニズムのキーを定義します. 他のクレデンシャルメカニズムは、HMACに使用されるキーを定義する必要があります.
HMACへの入力として使用されるテキストは、MESSAGE-INTEGRITY-SHA256属性に先行する属性までのSTUNメッセージです. STUNメッセージヘッダーの長さフィールドは、MESSAGE-INTEGRITY-SHA256属性の終わりを指すように調整されます. MESSAGE-INTEGRITY-SHA256属性の値は、ダミー値に設定されます.
計算が実行されると、MESSAGE-INTEGRITY-SHA256属性の値が入力され、STUNヘッダーの長さの値が正しい値（メッセージ全体の長さ）に設定されます. 同様に、MESSAGE-INTEGRITY-SHA256を検証するとき、STUNヘッダーのLengthフィールドは、STUNメッセージでHMACを計算する前に、MESSAGE-INTEGRITY-SHA256属性の終わりを指すように調整する必要があります. MESSAGE-INTEGRITY-SHA256属性の前. このような調整は、FINGERPRINTなどの属性がMESSAGE-INTEGRITY-SHA256の後に表示される場合に必要です. このような計算の例については、付録B.1も参照してください.
14.7. 指紋
FINGERPRINT属性は、すべてのSTUNメッセージに存在する場合があります.
属性の値は、32ビット値0x5354554eとXORされたFINGERPRINT属性自体までの（ただし除外する）STUNメッセージのCRC-32として計算されます. （XOR操作は、アプリケーションプロトコルによって生成されたCRC-32を含むパケットでFINGERPRINTテストが誤検出を報告しないことを保証します. ）32ビットCRCは、ITU V.42 [ITU.V42.2002で定義されたものです. ]、
x ^ 32 + x ^ 26 + x ^ 23 + x ^ 22 + x ^ 16 + x ^ 12 + x ^ 11 + x ^ 10 + x ^ 8 + x ^ 7 + x ^ 5 + xの生成多項式がある^ 4 + x ^ 2 + x + 1. [RFC1952]のセクション8のCRC-32のサンプルコードを参照してください.
存在する場合、FINGERPRINT属性はメッセージの最後の属性でなければならないため、MESSAGE-INTEGRITYおよびMESSAGE- INTEGRITY-SHA256の後に表示されます.
FINGERPRINT属性は、STUNパケットを他のプロトコルのパケットと区別するのに役立ちます. セクション7を参照してください.
MESSAGE-INTEGRITYおよびMESSAGE-INTEGRITY-SHA256と同様に、FINGERPRINT属性で使用されるCRCは、STUNメッセージヘッダーの長さフィールドをカバーします. したがって、CRCの計算の前に、この値は正しく、メッセージ長の一部としてCRC属性を含める必要があります. メッセージでFINGERPRINT属性を使用する場合、属性は最初にダミー値とともにメッセージに配置されます. 次に、CRCが計算され、属性の値が更新されます. MESSAGE-INTEGRITYまたはMESSAGE-INTEGRITY-SHA256属性も存在する場合、CRCがMESSAGE-INTEGRITYおよびMESSAGE- INTEGRITY-SHA256属性も同様です.
14.8. エラーコード
ERROR-CODE属性は、エラー応答メッセージで使用されます. 300〜699の範囲の数値エラーコード値と、UTF-8 [RFC3629]でエンコードされたテキストの理由フレーズが含まれています. また、SIP [RFC3261]およびHTTP [RFC7231]とのコード割り当ておよびセマンティクスも一貫しています. 理由句は、診断を目的としたものであり、エラーコードに適したものであれば何でもかまいません. 定義されたエラーコードの推奨理由フレーズは、エラーコードのIANAレジストリに含まれています. 理由フレーズは、128文字未満のUTF-8エンコード[RFC3629]シーケンスである必要があります（エンコード時は509バイト、デコード時は763バイト）.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved, should be 0 |Class| Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Phrase (variable) ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Format of ERROR-CODE Attribute
処理を容易にするために、エラーコードのクラス（数百桁）は、図7に示すように、残りのコードとは別にエンコードされます.
予約済みビットは0である必要があり、32ビット境界でのアライメント用です. 受信者はこれらのビットを無視しなければなりません. クラスは、エラーコードの数百桁を表します. 値は3〜6でなければなりません. Numberは、100を法とするエラーコードのバイナリエンコーディングを表し、その値は0〜99でなければなりません.
以下のエラーコードと、推奨される理由フレーズが定義されています.
300代替の試行：クライアントは、この要求について代替サーバーに接続する必要があります. このエラー応答は、リクエストにUSERNAMEまたはUSERHASH属性と有効なMESSAGE-INTEGRITYまたはMESSAGE-INTEGRITY-SHA256属性が含まれている場合にのみ送信する必要があります. それ以外の場合は、送信してはならず、エラーコード400（Bad Request）が提案されます. このエラー応答はMESSAGE-INTEGRITYまたはMESSAGE-INTEGRITY-SHA256属性で保護する必要があり、受信者はこの応答のMESSAGE-INTEGRITYまたはMESSAGE-INTEGRITY-SHA256を代替サーバーにリダイレクトする前に検証する必要があります.
注：300応答のメッセージ整合性の生成と検証に失敗すると、パス上の攻撃者が300応答を偽造し、後続のSTUNメッセージが被害者に送信される可能性があります.
400 Bad Request：リクエストの形式が正しくありません. クライアントは、前回の試行から変更せずにリクエストを再試行するべきではありません. サーバーはこのエラーに対して有効なMESSAGE-INTEGRITYまたはMESSAGE-INTEGRITY-SHA256を生成できない可能性があるため、クライアントはこの応答で有効なMESSAGE-INTEGRITYまたはMESSAGE-INTEGRITY-SHA256属性を期待してはなりません.
401認証されていない：要求には、続行するための正しい資格情報が含まれていませんでした. クライアントは適切な資格情報でリクエストを再試行する必要があります.
420不明な属性：サーバーは理解できない必須の属性を含むSTUNパケットを受信しました. サーバーは、エラー応答のUNKNOWN-ATTRIBUTE属性にこの不明な属性を配置する必要があります.
438 Stale Nonce：クライアントが使用したNONCEは無効になりました. クライアントは、応答で提供されたNONCEを使用して再試行する必要があります. 500サーバーエラー：サーバーで一時的なエラーが発生しました. クライアントは再試行する必要があります.
14.9. レルム
REALM属性は、要求と応答に存在する場合があります. [RFC3261]で説明されている「レルム値」の文法を満たすテキストが含まれていますが、二重引用符とその周囲の空白はありません. つまり、引用符で囲まれていないレルム値です（したがって、qdtextまたは引用符で囲まれたペアのシーケンスです）. 128文字未満のUTF-8エンコード[RFC3629]シーケンスでなければならず（エンコード時は509バイト、デコード時は763バイト）、OpaqueStringプロファイルを使用して処理する必要があります[ RFC8265].
要求にREALM属性が存在することは、Long-Term Credentialが認証に使用されていることを示します. 特定のエラー応答に存在することは、サーバーがクライアントが認証のためにそのレルムでLong-Term Credentialを使用することを望んでいることを示します.
14.10. 一回
NONCE属性は、リクエストとレスポンスに存在する場合があります. [RFC3261]で定義されているqdtextまたはquoted-pairのシーケンスが含まれています. これは、NONCE属性に実際の周囲の引用文字が含まれないことを意味することに注意してください. NONCE属性は、128文字未満でなければなりません（それらをエンコードする場合は509バイト、デコードする場合は763バイト）. サーバー内のナンス値の選択に関するガイダンスについては、[RFC7616]のセクション5.4を参照してください.
14.11. パスワードアルゴリズム
PASSWORD-ALGORITHMS属性は、要求と応答に存在する場合があります. これには、サーバーがLong-Term Passwordの導出に使用できるアルゴリズムのリストが含まれています.
既知のアルゴリズムのセットは、IANAによって管理されています. この仕様で定義されている初期セットはセクション18.5にあります.
この属性には、アルゴリズム番号と可変長パラメーターのリストが含まれています. アルゴリズム番号は、セクション18.5で定義されている16ビット値です. パラメーターは、パラメーターの長さ（パディング前）から16ビット値で始まり、その後に各アルゴリズムに固有のパラメーターが続きます. パラメーターは、属性と同じ方法で32ビット境界に埋め込まれます.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 1 | Algorithm 1 Parameters Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 1 Parameters (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 2 | Algorithm 2 Parameters Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 2 Parameters (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
Figure 8: Format of PASSWORD-ALGORITHMS Attribute
14.12. パスワードアルゴリズム
PASSWORD-ALGORITHM属性は、リクエストにのみ存在します. これには、Long-Term Passwordからキーを導出するためにサーバーが使用する必要があるアルゴリズムが含まれています.
既知のアルゴリズムのセットは、IANAによって管理されています. この仕様で定義されている初期セットはセクション18.5にあります.
属性には、アルゴリズム番号と可変長パラメーターが含まれます. アルゴリズム番号は、セクション18.5で定義されている16ビット値です. パラメーターは、16ビット値としてのパラメーターの長さ（パディング前）で始まり、その後にアルゴリズムに固有のパラメーターが続きます. パラメーターは、属性と同じ方法で32ビット境界に埋め込まれます. 同様に、送信時にパディングビットをゼロに設定する必要があり、受信者は無視する必要があります.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Algorithm Parameters Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm Parameters (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Format of PASSWORD-ALGORITHM Attribute
14.13. 未知の属性
UNKNOWN-ATTRIBUTES属性は、ERROR-CODE属性の応答コードが420（不明な属性）の場合、エラー応答にのみ存在します. 属性には、16ビット値のリストが含まれています. 各値は、サーバーが認識できない属性タイプを表します.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute 1 Type | Attribute 2 Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute 3 Type | Attribute 4 Type ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Format of UNKNOWN-ATTRIBUTES Attribute
注：[RFC3489]では、最後の属性を複製することにより、このフィールドに32が埋め込まれました. このバージョンの仕様では、属性の通常のパディングルールが代わりに使用されます.
14.14. ソフトウェア
SOFTWARE属性には、メッセージを送信するエージェントが使用しているソフトウェアの説明が含まれています. クライアントとサーバーで使用されます. その値には、製造元とバージョン番号を含める必要があります. この属性はプロトコルの動作に影響を与えず、診断およびデバッグの目的でのみツールとして機能します. SOFTWAREの値は可変長です. 128文字未満のUTF-8エンコード[RFC3629]シーケンスである必要があります（エンコード時は509、デコード時は763バイト）.
14.15. 代替サーバー
代替サーバーは、STUNクライアントが試行する別のSTUNサーバーを識別する代替トランスポートアドレスを表します.
これは、MAPPED-ADDRESSと同じ方法でエンコードされているため、IPアドレスで単一のサーバーを参照します.
14.16. 代替ドメイン
代替ドメインは、トランスポートプロトコルがTLSまたはDTLSを使用するときにALTERNATE-SERVER属性のIPアドレスを確認するために使用されるドメイン名を表します.
ALTERNATE-DOMAINの値は可変長です. 255文字以下のASCII文字の有効なDNS名[RFC1123]（Aラベル[RFC5890]を含む）でなければなりません.
15.操作上の考慮事項
STUNはエニーキャストアドレスで使用できますが、UDPおよび認証が使用されていないSTUN使用法でのみ使用できます.
16.セキュリティに関する考慮事項
TLSまたはDTLSを使用したSTUN Usageの実装と展開は、[BCP195]の推奨事項に従う必要があります.
long-term credential mechanism（セクション9.2）を使用したSTUN使用の実装と展開は、[RFC7616]のセクション5の推奨事項に従う必要があります.
16.1. プロトコルに対する攻撃
16.1.1. 外部からの攻撃
攻撃者は、STUN操作で障害を引き起こすために、転送中のSTUNメッセージを変更しようとする可能性があります. これらの攻撃は、短期または長期の資格情報を使用して、メッセージ整合性メカニズムを通じて要求と応答の両方に対して検出されます. もちろん、検出されると、操作されたパケットはドロップされ、STUNトランザクションは事実上失敗します. この攻撃は、パス上の攻撃者によってのみ可能です.
転送中のSTUNメッセージを観察できるが変更はできない攻撃者（たとえば、Wi-Fiなどの共有アクセスメディアに存在する攻撃者）は、STUN要求を確認し、すぐにSTUN応答（通常はエラー）を送信できます. 応答、STUN処理を中断するため. この攻撃は、MESSAGE-INTEGRITYを利用するメッセージでも防止されます. ただし、一部のエラー応答、特に認証に関連するエラー応答は、MESSAGE-INTEGRITYによって保護できません. STUN自体がセキュアなトランスポートプロトコル（TLSなど）で実行されている場合、これらの攻撃は完全に軽減されます.
STUNの用途によっては、これらの攻撃の影響は最小限であるため、軽減するためにメッセージの整合性は必要ありません. たとえば、STUNを基本的なSTUNサーバーに使用して、ICEで使用するサーバーの再帰候補を検出する場合、これらの攻撃は接続チェックフェーズで検出されるため、認証とメッセージの整合性は必要ありません. ただし、接続性チェック自体は、ICE全体の適切な動作のために保護が必要です. セクション13で説明したように、STUNの使用法では、認証とメッセージの整合性が必要な場合について説明します.
STUNは認証と整合性保護のために共有シークレットのHMACを使用するため、オフライン辞書攻撃の影響を受けます. 認証を利用する場合、オフライン辞書攻撃の影響を受けにくい強力なパスワードを使用する必要があります. TLSまたはDTLSを使用したチャネル自体の保護は、これらの攻撃を軽減します.
STUNはMESSAGE-INTEGRITYとMESSAGE-INTEGRITY-SHA256の両方をサポートします. これにより、STUNはオンパス攻撃者による入札ダウン攻撃の対象となります. 攻撃者はMESSAGE-INTEGRITY-SHA256属性を除去し、MESSAGE-INTEGRITY属性のみを残し、潜在的な脆弱性を悪用する可能性があります. TLSまたはDTLSを使用したチャネル自体の保護は、これらの攻撃を軽減します. STUNの将来のバージョンにおけるMESSAGE-INTEGRITYのサポートのタイムリーな削除が必要です.
注：パスワードハッシュにSHA-256を使用することは、ハッシュを計算するための比較的遅い最小時間を提供することにより、徹底的なパスワード検索を遅くすることを目的とする現代の標準を満たしません. Argon2 [Argon2]などのより良いアルゴリズムが利用可能ですが、[RFC7616]との一貫性のためにSHA-256が選択されました.
16.1.2. 内部攻撃
不正なクライアントは、大量のSTUN要求を送信することにより、サーバーに対してDoS攻撃を仕掛けようとする場合があります. 幸いなことに、STUN要求はサーバーによってステートレスに処理されるため、このような攻撃を効果的に開始することは困難です.
不正なクライアントは、STUNサーバーをリフレクターとして使用し、偽造されたソースIPアドレスとポートを使用して要求を送信する場合があります. そのような場合、応答はそのソースIPとポートに配信されます. 通常、STUN応答は要求よりも大きいため、データ量はわずかに増加しますが、この攻撃ではパケット数の増幅はありません（STUNサーバーはクライアントが送信するパケットごとに1パケットを送信します）. この攻撃は、入力ソースアドレスフィルタリングによって軽減されます.
SOFTWARE属性を介してエージェントの特定のソフトウェアバージョンを明らかにすると、セキュリティホールを含むことが知られているソフトウェアに対する攻撃に対してより脆弱になる可能性があります. 実装者は、SOFTWARE属性の使用を構成可能なオプションにする必要があります.
16.1.3. 入札攻撃
このドキュメントは、[RFC5389]で使用されたアルゴリズムであるMD5との互換性を確保しながら、long-term credential mechanismを使用するときにサーバー側に保存されたパスワードの機密性を保護する異なるアルゴリズムを選択する可能性を追加します. この選択は、サーバーがクライアントにPASSWORD-ALGORITHMS属性でサポートされているアルゴリズムのリストを送信し、クライアントが選択したアルゴリズムを含むPASSWORD-ALGORITHM属性を返送することにより機能します.
PASSWORD-ALGORITHMS属性は認証されていない応答で送信する必要があるため、MD5の最終的な脆弱性を悪用したいパス上の攻撃者は、保護されていない応答からPASSWORD-ALGORITHMS属性を取り除くだけで、クライアントは[RFC5389]で定義されたこのプロトコルのバージョンを実装していました.
この攻撃および他の同様の入札単価低下攻撃から保護するために、nonceには、使用されているセキュリティ機能を示す一連のセキュリティビットが追加されています. パスワードアルゴリズムの選択の場合、一致するビットは、PASSWORD- ALGORITHMS属性を含む同じ応答でサーバーから返されたナンスに設定されます. 後続の認証済みトランザクションで使用されるナンスは、最初に送信されたものと同一であることがサーバーによって検証されるため、パス上の攻撃者が変更することはできません. さらに、クライアントは、次の認証済みトランザクションで受信したPASSWORD-ALGORITHMS属性をそのサーバーにコピーすることを義務付けられています.
PASSWORD-ALGORITHMSを削除するパス上の攻撃は、クライアントが次の認証済みトランザクションでサーバーに送り返すことができないため、検出されます. セキュリティビットは設定されているが、一致する属性が欠落しているため、クライアントはその攻撃を検出します. これでセッションが終了します. このプロトコルの古いバージョンを使用するクライアントは、PASSWORD-ALGORITHMSを返送しませんが、とにかくMD5のみを使用できるため、攻撃は重要ではありません.
また、パス上の攻撃は、PASSWORD-ALGORITHMS属性とともにセキュリティビットを削除しようとする場合がありますが、サーバーは、次の認証済みトランザクションに無効なナンスが含まれていることを発見します.
PASSWORD- ALGORITHMS属性から一部のアルゴリズムを削除するオンパス攻撃は、サーバーが後続の認証済みトランザクションで検証するときに元の属性と異なるため、同様に無効になります.
このドキュメントで導入された値下げ保護メカニズムは、サーバーが401（認証されていない）応答の後に2番目の要求を受信するまで攻撃を検出できないという事実によって本質的に制限されることに注意してください.
[RFC7616]との互換性のために、パスワードハッシュの新しいデフォルトとしてSHA-256が選択されましたが、SHA-256（MD5など）は比較的高速なアルゴリズムであるため、ブルートフォース攻撃を阻止することはほとんどありません. 具体的には、ユーザーのパスワードが弱い場合、単一の交換をキャプチャする攻撃者はブルートフォース攻撃を使用してユーザーのパスワードを学習し、サーバーと同じパスワードが存在する他のサーバーにユーザーを偽装する可能性があることを意味します中古. このような攻撃者は、ブルートフォース攻撃を行うことなく、サーバー自体にユーザーを偽装できることに注意してください.
Argon2 [Argon2]のような強力な（つまり、遅い）アルゴリズムは、これらの両方の場合に役立ちます. ただし、最初のケースでは、このユーザーのデータベースエントリがその強力なメカニズムのみを使用するように更新された後にのみ役立ちます.
このプロトコルの入札ダウン防御は、攻撃者がクライアントとサーバーに、共同でサポートするよりも弱いアルゴリズムを使用してハンドシェイクを強制することを防ぎますが、それは、最も弱い共同アルゴリズムがブルートフォース攻撃によって侵害されないほど強力な場合のみです. ただし、これはこれらのアルゴリズムに対する多くの攻撃に対する防御ではありません. 具体的には、パス上の攻撃者は、パスワードハッシュのためにArgon2 [Argon2]とSHA-256の両方をサポートするクライアントで入札ダウン攻撃を実行し、それを使用してMESSAGE- INTEGRITY-SHA256値を収集しますオフラインの総当たり攻撃. これは、サーバーが2番目の要求を受信したときに検出されますが、攻撃者がMESSAGE-INTEGRITY-SHA256値を取得することを妨げません.
同様に、サーバーは機能がパス上で破棄されたことを検出するため、USERHASHメカニズムに対する攻撃はセッションの確立に成功しませんが、クライアントはUSERNAME属性でユーザー名を平文で送信することを確信しているため、開示していますそれを攻撃者に.
最後に、メッセージを保護するために使用されるHMACアルゴリズムの将来のアップグレードに入札ダウン保護メカニズムが採用された場合、現在のHMACアルゴリズムが既に危険にさらされている場合、限定的な保護のみを提供します.
16.2. 使用法に影響する攻撃
このセクションでは、STUNの使用に対して開始される可能性のある攻撃をリストします. 各STUNの使用法では、これらの攻撃が該当するかどうかを検討し、該当する場合は対策を検討する必要があります.
このセクションの攻撃のほとんどは、バインディング要求/応答トランザクションを介してSTUNクライアントが学習した再帰アドレスを変更する攻撃者を中心に展開します. 再帰アドレスの使用法は使用法の関数であるため、これらの攻撃の適用可能性と修復は使用法に固有です. 一般的な状況では、パス上の攻撃者による再帰アドレスの変更は簡単です. たとえば、STUNがUDP上で直接実行される一般的な状況を考えてみましょう. この場合、パス上の攻撃者は、STUNサーバーに到着する前に、バインディング要求のソースIPアドレスを変更できます. 次に、STUNサーバーはこのIPアドレスをXOR-MAPPED-ADDRESS属性でクライアントに返し、その（改ざんされた）IPアドレスとポートに応答を送り返します. 攻撃者がこの応答も傍受できる場合、クライアントに向けて送り返すことができます. メッセージ整合性の値は送信元IPアドレスをカバーできず、介在するNATはこの値を変更できる必要があるため、メッセージ整合性チェックを使用してこの攻撃から保護することはできません. 代わりに、以下にリストされている攻撃を防ぐ1つの解決策は、クライアントがICE [RFC8445]で行われているように、学習した反射アドレスを検証することです.
他の用途では、これらの攻撃を防ぐために他の手段を使用する場合があります.
16.2.1. 攻撃I：ターゲットに対する分散DoS（DDoS）
この攻撃では、攻撃者は1つまたは複数のクライアントに、意図したターゲットを指す同じ偽の再帰アドレスを提供します. これにより、STUNクライアントは、自分の再帰アドレスがターゲットのアドレスと等しいと考えるようになります. クライアントがトラフィックを受信するために（たとえば、SIPメッセージで）再帰アドレスを渡すと、代わりにトラフィックがターゲットに送信されます. この攻撃は、特にマルチメディアアプリケーションを有効にするためにSTUNを使用しているクライアントで使用する場合、大幅な増幅を提供できます. ただし、STUNサーバーからターゲットへのパケットが攻撃者を通過するターゲットに対してのみ起動でき、可能な場合を制限します.
16.2.2. 攻撃II：クライアントのサイレンシング
この攻撃では、攻撃者はSTUNクライアントに偽の再帰アドレスを提供します. それが提供する再帰アドレスは、どこにもルーティングされないトランスポートアドレスです. その結果、クライアントは、再帰アドレスを渡すときに受信すると予想されるパケットを受信しません. このエクスプロイトは、攻撃者にとってあまり興味深いものではありません. 単一のクライアントに影響を与えますが、これは多くの場合、望ましいターゲットではありません. さらに、攻撃を仕掛けることができる攻撃者は、クライアントがSTUNサーバーやDHCPサーバーからの応答を受信できないようにするなど、他の手段によってクライアントへのサービスを拒否することもできます. セクション16.2.1で説明した攻撃と同様に、この攻撃は、攻撃者がSTUNサーバーからこの未使用IPアドレスに向けて送信されたパケットのパス上にある場合にのみ可能です. 16.2.3. 攻撃III：
この攻撃は、攻撃IIに似ています. ただし、偽の再帰アドレスは攻撃者自体を指します. これにより、攻撃者はクライアント宛てのトラフィックを受信できます.
16.2.4. 攻撃IV：盗聴
この攻撃では、攻撃者はクライアントに自分自身にルーティングする再帰アドレスを使用するように強制します. 次に、受信したパケットをクライアントに転送します. この攻撃により、攻撃者はクライアントに送信されたすべてのパケットを監視できます. ただし、攻撃を開始するためには、攻撃者はクライアントからSTUNサーバーへのパケットを既に監視できている必要があります. ほとんどの場合（アクセスネットワークから攻撃が開始された場合など）、これは攻撃者がクライアントに送信されたパケットを既に観測できることを意味します. その結果、この攻撃は、クライアントからSTUNサーバーへのパス上の攻撃者によるトラフィックを監視するためにのみ有用ですが、一般的にクライアントにルーティングされるパケットのパス上にはありません.
この攻撃はSTUNサーバー自体によって簡単に起動できるため、STUNサーバーのユーザーは、自身を通信フローに挿入できる他のノードと同じレベルの信頼をSTUNサーバーのユーザーに持つ必要があります.
16.3. ハッシュアジリティ計画
この仕様では、メッセージの整合性の計算にHMAC-SHA256を使用し、HMAC-SHA1と組み合わせることもあります. 後で、HMAC-SHA256が侵害されていることが判明した場合、次の新しいメッセージ整合性の修正属性の値は、新しいハッシュを使用して計算されます. STUNセキュリティ機能ビットは、1）このサーバーがこの新しいハッシュアルゴリズムをサポートするというlong-term credential mechanismを使用してSTUNクライアントに信号を送り、2）新しいメッセージ整合性属性に対する入札ダウン攻撃を防ぐために使用されます.
oshort-term credential mechanismを使用するSTUNクライアントおよびサーバーは、使用しているメッセージ整合性属性を通知するために使用する外部メカニズムを更新する必要があります.
このドキュメントで説明されている入札単価低下の保護メカニズムは新しいため、現在、ハッシュアルゴリズムの強度をHMAC-SHA1に低下させる入札単価低下攻撃から保護することはできません. これが、移行期間後、これを更新する新しいドキュメントが、HMAC-SHA1を廃止するための新しいSTUNセキュリティ機能ビットを割り当てる理由です. このビットを使用すると、HMAC-SHA1が非推奨になり、使用する必要がなくなります. 新しいハッシュを使用して計算された値. STUNセキュリティ機能ビットは、1）このサーバーがuserhash属性に対してこの新しいハッシュアルゴリズムをサポートしているというlong-term credential mechanismを使用してSTUNクライアントに信号を送り、2）新しいuserhash属性に対する入札ダウン攻撃を防ぐために使用されます.
17. IABの考慮事項
IABは、Unilateral Self-Address Fixing（UNSAF）の問題を研究しました. これは、クライアントが協調プロトコルリフレクションメカニズム[RFC3424]を介してNATの反対側の別の領域でアドレスを決定しようとする一般的なプロセスです. 一方のエージェントがNATの背後にあり、他方のエージェントがNATのパブリック側にある場合、バインディング要求/応答トランザクションを使用してこの機能を実行するためにSTUNを使用できます.
IABは、この目的のために開発されたプロトコルが特定の考慮事項を文書化することを提案しています. 一部のSTUN使用法はUNSAF機能（ICE [RFC8445]など）を提供し、他の機能は提供しない（SIPアウトバウンド[RFC5626]など）ため、これらの考慮事項への回答は使用法自体で対処する必要があります.
18. IANAの考慮事項
18.1. STUNセキュリティ機能レジストリ
STUNセキュリティ機能セットは、フラグとして24ビットを定義します.
IANAは、セクション9.2.1で説明されている入札ダウン攻撃防止メカニズムによって保護されているSTUNセキュリティ機能を含む新しいレジストリを作成しました.
初期のSTUNセキュリティ機能は次のとおりです.
ビット0：パスワードアルゴリズムビット1：ユーザー名の匿名性ビット2-23：未割り当て
ビットはビットセットの最上位側から割り当てられるため、ビット0は左端のビットで、ビット23は右端のビットです.
新しいセキュリティ機能は、Standards Action [RFC8126]によって割り当てられます.
18.2. STUNメソッドレジストリ
STUNメソッドは、0x000-0x0FFの範囲の16進数です. STUNメソッドのSTUNメッセージへのエンコードについては、セクション5で説明します.
0x000-0x07Fの範囲のSTUNメソッドは、IETFレビュー[RFC8126]によって割り当てられます. 範囲0x080-0x0FFのSTUNメソッドは、エキスパートレビュー[RFC8126]によって割り当てられます. 専門家の責任は、選択したコードポイントが使用されていないこと、および要求が異常に多数のコードポイントに対するものではないことを確認することです. 拡張機能自体の技術的なレビューは、指定された専門家の責任の範囲外です.
IANAは、以下で説明するようにメソッド0x002の名前を更新し、次のSTUNメソッドの参照をRFC 5389からRFC 8489に更新しました.
0x000：予約済み0x001：バインディング0x002：予約済み. [RFC5389]より前にSharedSecretでした
18.3. STUN属性レジストリ
STUN属性タイプは、0x0000-0xFFFFの範囲の16進数です. 0x0000-0x7FFFの範囲のSTUN属性タイプは、理解が必要と見なされます. 0x8000-0xFFFFの範囲のSTUN属性タイプは、内包オプションと見なされます. STUNエージェントは、不明な理解が必要な属性と理解がオプションの属性を別々に処理します.
理解が必要な範囲の前半（0x0000-0x3FFF）および理解が必要な範囲の前半（0x8000-0xBFFF）のSTUN属性タイプは、IETF Review [RFC8126]によって割り当てられます. 理解が必要な範囲の後半（0x4000-0x7FFF）および理解が必要な範囲の後半（0xC000-0xFFFF）のSTUN属性タイプは、エキスパートレビュー[RFC8126]によって割り当てられます. 専門家の責任は、選択したコードポイントが使用されていないこと、および要求が異常に多数のコードポイントに対するものではないことを確認することです. 拡張機能自体の技術的なレビューは、指定された専門家の責任の範囲外です.
18.3.1. 更新された属性
IANAは、次のSTUNメソッドごとに、属性0x0002、0x0004、0x0005、0x0007、および0x000Bの名前を更新し、RFC 5389からRFC 8489への参照を更新しました.
さらに、[RFC5389]は属性0x0003の名前に誤りを導入しました. [RFC5389]実際に以前にCHANGE-REQUESTと呼ばれていたとき、それをCHANGE-ADDRESSと呼びました. したがって、IANAは0x0003の説明を更新して、「予約済み; [RFC5389]より前にCHANGE-REQUESTでした」と読みました.
理解が必要な範囲（0x0000-0x7FFF）：0x0000：予約済み0x0001：MAPPED-ADDRESS 0x0002：予約済み. [RFC5389] 0x0003より前のRESPONSE-ADDRESSでした：予約済み. [RFC5389] 0x0004より前のCHANGE-REQUEST：予約済み. [RFC5389] 0x0005以前のSOURCE-ADDRESS：予約済み. [RFC5389]の前にCHANGED-ADDRESSでした0x0006：USERNAME 0x0007：予約済み. [RFC5389]より前のパスワードでした0x0008：MESSAGE-INTEGRITY 0x0009：ERROR-CODE 0x000A：UNKNOWN-ATTRIBUTES 0x000B：予約済み; [RFC5389]より前にREFLECTED-FROMでした0x0014：REALM 0x0015：NONCE 0x0020：XOR-MAPPED-ADDRESS
理解オプション範囲（0x8000-0xFFFF）0x8022：ソフトウェア0x8023：ALTERNATE-SERVER 0x8028：FINGERPRINT
18.3.2. 新しい属性
IANAは、次の属性を「STUN属性」レジストリに追加しました.
理解が必要な範囲（0x0000-0x7FFF）：0x001C：MESSAGE-INTEGRITY-SHA256 0x001D：PASSWORD-ALGORITHM 0x001E：USERHASH
理解オプションの範囲（0x8000-0xFFFF）0x8002：PASSWORD-ALGORITHMS 0x8003：ALTERNATE-DOMAIN
18.4. STUNエラーコードレジストリ
STUNエラーコードは、0〜699の範囲の数値です. STUNエラーコードには、UTF-8 [RFC3629]のテキストによる理由句が付随しています. このドキュメントでは、推奨値のみを提案しています.
STUNエラーコードは、コードポイントの割り当てとSIP [RFC3261]およびHTTP [RFC7231]とのセマンティクスで一貫しています.
IETFレビュー[RFC8126]に基づいて、新しいSTUNエラーコードが割り当てられます. 仕様では、このエラーコードを理解していないクライアントがリクエストを許可する前にどのように処理するかを慎重に検討する必要があります. セクション6.3.4のルールを参照してください.
IANAは、セクション14.8で定義されているエラーコードについて、RFC 5389からRFC 8489への参照を更新しました.
IANAは401エラーコードの名前を「Unauthorized」から「Unauthenticated」に変更しました.
18.5. STUNパスワードアルゴリズムレジストリ
IANAは、「STUNパスワードアルゴリズム」というタイトルの新しいレジストリを作成しました.
パスワードアルゴリズムは、0x0000-0xFFFFの範囲の16進数です.
「パスワードアルゴリズム」レジストリの初期内容は次のとおりです.
0x0000：予約済み0x0001：MD5 0x0002：SHA-256 0x0003-0xFFFF：未割り当て
範囲の前半（0x0000-0x7FFF）のパスワードアルゴリズムは、IETFレビュー[RFC8126]によって割り当てられます. 範囲の後半（0x8000-0xFFFF）のパスワードアルゴリズムは、エキスパートレビュー[RFC8126]によって割り当てられます.
18.5.1. パスワードアルゴリズム
18.5.1.1. MD5
このパスワードアルゴリズムは[RFC1321]から取得されます.
キーの長さは16バイトで、パラメーター値は空です.
注：このアルゴリズムは、レガシーシステムとの互換性のためにのみ使用する必要があります.
key = MD5（username "：" OpaqueString（realm） "：" OpaqueString（password））
18.5.1.2. SHA-256
このパスワードアルゴリズムは[RFC7616]から取得されます.
キーの長さは32バイトで、パラメーター値は空です.
key = SHA-256（username "：" OpaqueString（realm） "：" OpaqueString（password））
18.6. STUN UDPおよびTCPポート番号
IANAは、「サービス名とトランスポートプロトコルポート番号レジストリ」の次のポートについて、RFC 5389からRFC 8489への参照を更新しました.
stun 3478 / tcp NAT（STUN）ポートのセッショントラバースユーティリティstun 3478 / udp NAT（STUN）ポートのセッショントラバースユーティリティstuns 5349 / tcp NAT（STUN）ポートのセッショントラバースユーティリティ
19. RFC 5389以降の変更
この仕様は、[RFC5389]を廃止します. この仕様は、次の点でRFC 5389と異なります.
o DTLS-over-UDP [RFC6347]のサポートを追加しました.
oサーバーとのトランザクションがない場合、RTOは古いと見なされることを明確にしました.
o RTO計算を[RFC6298]に合わせました.
o TLSの暗号スイートを更新しました.
o STUN URI [RFC7064]のサポートを追加しました. o SHA256メッセージ整合性のサポートが追加されました.
o [RFC8265]への国際化文字列の準備、実施、および比較（PRECIS）サポートを更新しました.
oパスワード暗号化アルゴリズムを選択するためのプロトコルとレジストリを追加しました.
o匿名ユーザー名のサポートを追加しました.
o入札単価の低下を防ぐためのプロトコルとレジストリを追加しました.
o NONCEの共有はもはや許可されないことを指定しました.
o代替サーバーメカニズムでドメイン名を使用する可能性が追加されました.
o Cスニペットを追加しました.
oテストベクターを追加しました.
20.参照
20.1. 規範的参考文献
[ITU.V42.2002]国際電気通信連合、「非同期から同期への変換を使用したDCEのエラー修正手順」、ITU-T勧告V.42、2002年3月.
[KARN87]カーン、P. およびC.パートリッジ、「信頼性の高いトランスポートプロトコルでの往復時間推定の改善」、SIGCOMM '87、コンピューター通信技術のフロンティアに関するACMワークショップの議事録、ページ2-7、DOI 10.1145 / 55483.55484 、1987年8月.
[RFC0791]ポステル、J. 、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487 / RFC0791、1981年9月、<https://www.rfc-editor.org/info/rfc791>.
[RFC1122]ブレーデン、R. 、エド、「インターネットホストの要件-通信層」、STD 3、RFC 1122、DOI 10.17487 / RFC1122、1989年10月、<https://www.rfc-editor.org/info/ rfc1122>.
[RFC1123]ブレーデン、R. 、「インターネットホストの要件-アプリケーションとサポート」、STD 3、RFC 1123、DOI 10.17487 / RFC1123、1989年10月、<https://www.rfc-editor.org/info / rfc1123> .
[RFC1321] Rivest、R. 、「MD5メッセージダイジェストアルゴリズム」、RFC 1321、DOI 10.17487 / RFC1321、1992年4月、<https://www.rfc-editor.org/info/rfc1321>.
[RFC2104] Krawczyk、H.、Bellare、M. 、およびR. Canetti、「HMAC：メッセージ認証のためのキー付きハッシュ」、RFC 2104、DOI 10.17487 / RFC2104、1997年2月、<https：//www.rfc-editor .org / info / rfc2104>.
[RFC2119] Bradner、S.、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>.
[RFC2782] Gulbrandsen、A.、Vixie、P. 、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、DOI 10.17487 / RFC2782、2000年2月、<https：// www.rfc-editor.org/info/rfc2782>.
[RFC3629] Yergeau、F. 、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https://www.rfc-editor.org/info/ rfc3629>.
[RFC4648] Josefsson、S. 、「The Base16、Base32、およびBase64 Data Encodings」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<https://www.rfc-editor.org/info/rfc4648>.
[RFC5890] Klensin、J.、「アプリケーションの国際化ドメイン名（IDNA）：定義とドキュメントフレームワーク」、RFC 5890、DOI 10.17487 / RFC5890、2010年8月、<https://www.rfc-editor.org/info/ rfc5890>.
[RFC6125] Saint-Andre、P.およびJ. Hodges、「トランスポート層セキュリティ（TLS）のコンテキストでX.​​509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 RFC 6125、DOI 10.17487 / RFC6125、2011年3月、<https://www.rfc-editor.org/info/rfc6125>.
[RFC6151] Turner、S. およびL. Chen、「MD5メッセージダイジェストおよびHMAC-MD5アルゴリズムのセキュリティに関する考慮事項の更新」、RFC 6151、DOI 10.17487 / RFC6151、2011年3月、<https：//www.rfc- editor.org/info/rfc6151>. [RFC6298] Paxson、V.、Allman、M.、Chu、J. 、およびM. Sargent、「TCPの再送信タイマーの計算」、RFC 6298、DOI 10.17487 / RFC6298、2011年6月、<https：//www.rfc- editor.org/info/rfc6298>.
[RFC6347] Rescorla、E. およびN. Modadugu、「データグラムトランスポートレイヤーセキュリティバージョン1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<https://www.rfc-editor.org/info/rfc6347>.
[RFC7064] Nandakumar、S.、Salgueiro、G.、Jones、P. 、およびM. Petit- Huguenin、「NAT（STUN）プロトコルのセッショントラバーサルユーティリティのURIスキーム」、RFC 7064、DOI 10.17487 / RFC7064、11月2013、<https://www.rfc-editor.org/info/rfc7064>.
[RFC7350] Petit-Huguenin、M. 、およびG. Salgueiro、「NAT（STUN）のセッショントラバーサルユーティリティのトランスポートとしてのDatagram Transport Layer Security（DTLS）」、RFC 7350、DOI 10.17487 / RFC7350、2014年8月、<https：/ /www.rfc-editor.org/info/rfc7350>.
[RFC7616] Shekh-Yusef、R.、Ed. 、Ahrens、D. 、およびS. Bremer、「HTTPダイジェストアクセス認証」、RFC 7616、DOI 10.17487 / RFC7616、2015年9月、<https：//www.rfc- editor.org/info/rfc7616>.
[RFC8174] Leiba、B. 、「RFC 2119キーワードでの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>.
[RFC8200] Deering、S. およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487 / RFC8200、2017年7月、<https://www.rfc-editor.org / info / rfc8200>.
[RFC8265] Saint-Andre、P. およびA. Melnikov、「ユーザー名とパスワードを表す国際化された文字列の準備、施行、比較」、RFC 8265、DOI 10.17487 / RFC8265、2017年10月、<https：//www.rfc- editor.org/info/rfc8265>.
[RFC8305] Schinazi、D. and T. Pauly、 "Happy Eyeballs Version 2：Better Connectivity Using Concurrency"、RFC 8305、DOI 10.17487 / RFC8305、December 2017、<https://www.rfc-editor.org/info/ rfc8305>.
20.2. 参考資料
[Argon2] Biryukov、A.、Dinu、D.、Khovratovich、D. 、およびS. Josefsson、「記憶力の強いArgon2パスワードハッシュと証明機能」、Work in Progress、draft-irtf- cfrg-アルゴン2-09、2019年11月.
[BCP195] Sheffer、Y.、Holz、R. 、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、2015年5月、<https://www.rfc-editor.org/info/bcp195>.
[RFC1952] Deutsch、P. 、「GZIPファイル形式仕様バージョン4.3」、RFC 1952、DOI 10.17487 / RFC1952、1996年5月、<https://www.rfc-editor.org/info/rfc1952>.
[RFC2279] Yergeau、F. 、「UTF-8、変換フォーマットISO 10646」、RFC 2279、DOI 10.17487 / RFC2279、1998年1月、<https://www.rfc-editor.org/info/rfc2279>.
[RFC3261]ローゼンバーグ、J. 、シュルズリンネ、H. 、カマリロ、G. 、ジョンストン、A. 、ピーターソン、J. 、スパークス、R. 、ハンドリー、M. 、およびE.スクーラー、「SIP：Session Initiation Protocol」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>.
[RFC3424] Daigle、L.、Ed. およびIAB、「ネットワークアドレス変換全体にわたる一方的な自己アドレス修正（UNSAF）に関するIABの考慮事項」、RFC 3424、DOI 10.17487 / RFC3424、2002年11月、<https://www.rfc-editor.org/info/rfc3424>.
[RFC3454] Hoffman、P. およびM. Blanchet、「国際化文字列の準備（ "stringprep"）」、RFC 3454、DOI 10.17487 / RFC3454、2002年12月、<https://www.rfc-editor.org/info/ rfc3454>.
[RFC3489] Rosenberg、J.、Weinberger、J.、Huitema、C. 、およびR. Mahy、「STUN-ネットワークアドレス変換器（NAT）を介したユーザーデータグラムプロトコル（UDP）の単純なトラバース」、RFC 3489、DOI 10.17487 / RFC3489、2003年3月、<https://www.rfc-editor.org/info/rfc3489>.
[RFC4013] Zeilenga、K. 、「SASLprep：ユーザー名とパスワードのStringprepプロファイル」、RFC 4013、DOI 10.17487 / RFC4013、2005年2月、<https://www.rfc-editor.org/info/rfc4013>.
[RFC4107] Bellovin、S. 、およびR. Housley、「暗号鍵管理のガイドライン」、BCP 107、RFC 4107、DOI 10.17487 / RFC4107、2005年6月、<https://www.rfc-editor.org/info/rfc4107 >.
[RFC5090] Sterman、B.、Sadolevsky、D.、Schwartz、D.、Williams、D. 、およびW. Beck、「ダイジェスト認証のためのRADIUS拡張機能」、RFC 5090、DOI 10.17487 / RFC5090、2008年2月、<https： //www.rfc-editor.org/info/rfc5090>.
[RFC5389]ローゼンバーグ、J. 、マヒー、R. 、マシューズ、P. 、およびD.ウィング、「NAT（STUN）のセッショントラバースユーティリティ」、RFC 5389、DOI 10.17487 / RFC5389、2008年10月、<https：// www.rfc-editor.org/info/rfc5389>.
[RFC5626] Jennings、C.、Ed. 、Mahey、R.、Ed. 、およびF. Audet、Ed. 、「セッション開始プロトコル（SIP）でのクライアント開始接続の管理」、RFC 5626、DOI 10.17487 / RFC5626 、2009年10月、<https://www.rfc-editor.org/info/rfc5626>.
[RFC5766] Mahy、R.、Matthews、P.、およびJ. Rosenberg、「NATの周りのリレーを使用したトラバーサル（TURN）：NAT（STUN）のセッショントラバーサルユーティリティへのリレー拡張」、RFC 5766、DOI 10.17487 / RFC5766、4月2010、<https://www.rfc-editor.org/info/rfc5766>.
[RFC5769] Denis-Courmont、R. 、「NAT（STUN）のセッショントラバーサルユーティリティのテストベクトル」、RFC 5769、DOI 10.17487 / RFC5769、2010年4月、<https://www.rfc-editor.org/info/ rfc5769>.
[RFC5780] MacDonald、D. 、およびB. Lowekamp、「NAT（STUN）のセッショントラバーサルユーティリティを使用したNAT動作発見」、RFC 5780、DOI 10.17487 / RFC5780、2010年5月、<https://www.rfc-editor.org / info / rfc5780>.
[RFC6544]ローゼンバーグ、J. 、ケラネン、A. 、ローカンプ、B. 、およびA.ローチ、「対話型接続確立（ICE）を使用したTCP候補」、RFC 6544、DOI 10.17487 / RFC6544、2012年3月、<https：/ /www.rfc-editor.org/info/rfc6544>.
[RFC7231]フィールディング、R. 、エド. およびJ. Reschke、Ed. 、「ハイパーテキスト転送プロトコル（HTTP / 1.1）：セマンティクスとコンテンツ」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<https://www.rfc-editor.org/info/rfc7231 >.
[RFC8126] Cotton、M.、Leiba、B. 、およびT. Narten、「RFCでIANA考慮事項セクションを記述するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>.
[RFC8264] Saint-Andre、P. and M. Blanchet、 "PRECIS Framework：Preparation、Enforcement、and Internationalized Strings in Application Protocols"、RFC 8264、DOI 10.17487 / RFC8264、October 2017、<https：// www. rfc-editor.org/info/rfc8264>.
[RFC8445] Keranen、A.、Holmberg、C. 、およびJ. Rosenberg、「Interactive Connectivity Establishment（ICE）：ネットワークアドレス変換（NAT）トラバーサルのプロトコル」、RFC 8445、DOI 10.17487 / RFC8445、2018年7月、< https://www.rfc-editor.org/info/rfc8445>.
[RFC8446] Rescorla、E. 、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>.
[STUN-PMTUD] Petit-Huguenin、M.、Salgueiro、G. 、およびF. Garrido、「NAT（STUN）のセッショントラバーサルユーティリティを使用したUDPトランスポートのパケット化レイヤーパスMTUディスカバリー（PLMTUD）」、Work in Progress、draft -ietf-tram-stun-pmtud-15、2019年12月
[UAX15] Unicode Standard Annex＃15、「Unicode Normalization Forms」、Mark DavisおよびKen Whistlerが編集. Unicode標準の不可欠な部分、<http://unicode.org/reports/tr15/>.
付録A. STUNメッセージタイプを決定するCスニペット
msg_typeパラメーターでホストバイト順の16ビットSTUNメッセージタイプ値を指定すると、STUNメッセージタイプを決定するCマクロが以下になります.
<コードの始まり> #define IS_REQUEST（msg_type）（（（msg_type）＆0x0110）== 0x0000）#define IS_INDICATION（msg_type）（（（（msg_type）＆0x0110）== 0x0010）#define IS_SUCCESS_RESP（msg_type）（（（msg_type ）＆0x0110）== 0x0100）#define IS_ERR_RESP（msg_type）（（（msg_type）＆0x0110）== 0x0110）<CODE ENDS>
メソッドとクラスをメッセージタイプに変換する関数：
<CODE BEGINS> int type（int method、int cls）{return（method＆0x1F80）<< 2 | （メソッド＆0x0070）<< 1 | （メソッド＆0x000F）| （cls＆0x0002）<< 7 | （cls＆0x0001）<< 4; } <コード終了>
メッセージタイプからメソッドを抽出する関数：
<CODE BEGINS> int method（int type）{return（type＆0x3E00）>> 2 | （タイプ＆0x00E0）>> 1 | （タイプ＆0x000F）; } <コード終了>
メッセージタイプからクラスを抽出する関数：
<CODE BEGINS> int cls（int type）{return（type＆0x0100）>> 7 | （タイプ＆0x0010）>> 4; } <コード終了>
付録B.テストベクトル
このセクションは、[RFC5769]で定義されたテストベクトルのリストをMESSAGE-INTEGRITY-SHA256で拡張します. [RFC5769]のセクション2にリストされているすべての形式と定義がここに適用されます.
B.1. MESSAGE- INTEGRITY-SHA256およびUSERHASHを使用した長期認証のサンプルリクエスト
このリクエストは次のパラメータを使用します.
ユーザー名： "<U + 30DE> <U + 30C8> <U + 30EA> <U + 30C3> <U + 30AF> <U + 30B9>"（引用符なし）OpaqueString [RFC8265]処理の影響を受けない
パスワード：「The <U + 00AD> M <U + 00AA> tr <U + 2168>」および「TheMatrIX」（引用符なし）は、OpaqueString [RFC8265]処理の前後にそれぞれ
Nonce： "obMatJos2AAACf // 499k954d6OL34oL9FSTvy64sA"（引用符なし）
レルム： "example.org"（引用符なし）
00 01 00 9c要求タイプとメッセージ長21 12 a4 42マジックCookie 78 ad 34 33} c6 ad 72 c0}トランザクションID 29 da 41 2e} 00 1e 00 20 USERHASH属性ヘッダー4a 3c f3 8f} ef 69 92 bd} a9 52 c6 78} 04 17 da 0f}ユーザーハッシュ値（32バイト）24 81 94 15} 56 9e 60 b2} 05 c4 6e 41} 40 7f 17 04} 00 15 00 29 NONCE属性ヘッダー6f 62 4d 61} 74 4a 6f 73} 32 41 41 41} 43 66 2f 2f} 34 39 39 6b}ノンス値とパディング（3バイト）39 35 34 64} 36 4f 4c 33} 34 6f 4c 39} 46 53 54 76} 79 36 34 73} 41 00 00 00} 00 14 00 0b REALM属性ヘッダー65 78 61 6d} 70 6c 65 2e}レルム値（11バイト）およびパディング（1バイト）6f 72 67 00} 00 1c 00 20 MESSAGE-INTEGRITY-SHA256属性ヘッダーe4 68 6c 8f} 0e de b5 90} 13 e0 70 90} 01 0a 93 ef}HMAC-SHA256値cc bc cc 54} 4c 0a 45 d9} f8 30 aa 6d} 6f 73 5a 01}
謝辞
Michael Tuexen、Tirumaleswar Reddy、Oleg Moskalenko、Simon Perreault、Benjamin Schwartz、Rifaat Shekh-Yusef、Alan Johnston、Jonathan Lennox、Brandon Williams、Olle Johansson、Martin Thomson、Mihaly Meszaros、Tolga Asveren、Noriyuki Doraw、Denceraw Dsawこのドキュメントの改善に役立つコメント、提案、質問については、ウォーリー、マシューミラー、ピーターサンアンドレ、ジュリアンエリー、ミルジャキューレウィンド、エリックレスコーラ、ベンキャンベル、アダムローチ、アレクセイメルニコフ、ベンジャミンカドゥックについて.
RFC 5389の謝辞セクションは次のように表示されました.
著者は、セドリック・アウン、ピート・コーデル、カレン・ジェニングス、ボブ・ペンフィールド、ザビエル・マージュ、マグヌス・ウェスターランド、ミゲル・ガルシア、ブルース・ローカンプ、クリス・サリバンにコメントを、バルーチ・スターマンとアラン・ホーリーライシェンに感謝します. この作業に関するIESGおよびIABのインプットについて、Leslie Daigle、Allison Mankin、Eric Rescorla、およびHenning Schulzrinneに感謝します.
寄稿者
Christian HuitemaとJoel Weinbergerは、RFC 3489の元の共著者でした.
著者のアドレス
マークプチフグナンインピーダンスミスマッチ
メール：[email protected]
Gonzalo Salgueiro Cisco 7200-12 Kit Creek Road Research Triangle Park、NC 27709アメリカ合衆国
電子メール：[email protected]
ジョナサン・ローゼンバーグ・ファイブ9ニュージャージー州エジソンアメリカ合衆国
メール：[email protected] URI：http://www.jdrosen.net
ダンウィングCitrix Systems、Inc.アメリカ合衆国
メール：[email protected]
Rohan Mahy Unaffiliated
メール：[email protected]
Philip Matthews Nokia 600 March Roadオンタリオ州オタワK2K 2T6カナダ
電話：613-784-3139メール：[email protected]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment