[要約] RFC 7635は、STUNプロトコルの拡張であり、第三者の認可を可能にするものです。その目的は、NATトラバーサルのセッションをサポートし、セキュリティとプライバシーを向上させることです。
Internet Engineering Task Force (IETF) T. Reddy
Request for Comments: 7635 P. Patil
Category: Standards Track R. Ravindranath
ISSN: 2070-1721 Cisco
J. Uberti
Google
August 2015
Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization
サードパーティ認証用のNAT（STUN）拡張用のセッショントラバーサルユーティリティ
Abstract
概要
This document proposes the use of OAuth 2.0 to obtain and validate ephemeral tokens that can be used for Session Traversal Utilities for NAT (STUN) authentication. The usage of ephemeral tokens ensures that access to a STUN server can be controlled even if the tokens are compromised.
このドキュメントでは、OAuth 2.0を使用して、NAT（STUN）認証用のセッショントラバーサルユーティリティに使用できる一時トークンを取得して検証することを提案しています。エフェメラルトークンを使用すると、トークンが危険にさらされている場合でも、STUNサーバーへのアクセスを確実に制御できます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7635.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7635で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Usage with TURN . . . . . . . . . . . . . . . . . . . . . 4
4. Obtaining a Token Using OAuth . . . . . . . . . . . . . . . . 7
4.1. Key Establishment . . . . . . . . . . . . . . . . . . . . 8
4.1.1. HTTP Interactions . . . . . . . . . . . . . . . . . . 8
4.1.2. Manual Provisioning . . . . . . . . . . . . . . . . . 10
5. Forming a Request . . . . . . . . . . . . . . . . . . . . . . 10
6. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. THIRD-PARTY-AUTHORIZATION . . . . . . . . . . . . . . . . 10
6.2. ACCESS-TOKEN . . . . . . . . . . . . . . . . . . . . . . 11
7. STUN Server Behavior . . . . . . . . . . . . . . . . . . . . 13
8. STUN Client Behavior . . . . . . . . . . . . . . . . . . . . 14
9. TURN Client and Server Behavior . . . . . . . . . . . . . . . 14
10. Operational Considerations . . . . . . . . . . . . . . . . . 15
11. Security Considerations . . . . . . . . . . . . . . . . . . . 15
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
12.1. Well-Known 'stun-key' URI . . . . . . . . . . . . . . . 16
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Sample Tickets . . . . . . . . . . . . . . . . . . . 20
Appendix B. Interaction between the Client and Authorization
Server . . . . . . . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
Session Traversal Utilities for NAT (STUN) [RFC5389] provides a mechanism to control access via 'long-term' username/password credentials that are provided as part of the STUN protocol. It is expected that these credentials will be kept secret; if the credentials are discovered, the STUN server could be used by unauthorized users or applications. However, in web applications like WebRTC [WEBRTC] where JavaScript uses the browser functionality for making real-time audio and/or video calls, web conferencing, and direct data transfer, ensuring this secrecy is typically not possible.
NAT用セッショントラバーサルユーティリティ（STUN）[RFC5389]は、STUNプロトコルの一部として提供される「長期」のユーザー名/パスワード資格情報を介してアクセスを制御するメカニズムを提供します。これらの資格情報は秘密にしておくことが期待されます。資格情報が発見された場合、STUNサーバーは権限のないユーザーまたはアプリケーションによって使用される可能性があります。ただし、WebRTC [WEBRTC]などのWebアプリケーションでは、JavaScriptがブラウザの機能を使用して、リアルタイムの音声通話やビデオ通話、Web会議、直接データ転送を行うため、通常はこの機密性を確保できません。
To address this problem and the ones described in [RFC7376], this document proposes the use of third-party authorization using OAuth 2.0 [RFC6749] for STUN. Using OAuth 2.0, a client obtains an ephemeral token from an authorization server, e.g., a WebRTC server, and the token is presented to the STUN server instead of the traditional mechanism of presenting username/password credentials. The STUN server validates the authenticity of the token and provides required services. Third-party authorization using OAuth 2.0 for STUN explained in this specification can also be used with Traversal Using Relays around NAT (TURN) [RFC5766].
この問題と[RFC7376]で説明されている問題に対処するために、このドキュメントでは、STUNにOAuth 2.0 [RFC6749]を使用したサードパーティ認証の使用を提案しています。 OAuth 2.0を使用して、クライアントは一時的なトークンを認証サーバー（WebRTCサーバーなど）から取得し、トークンは、ユーザー名/パスワードの資格情報を提示する従来のメカニズムではなく、STUNサーバーに提示されます。 STUNサーバーはトークンの信頼性を検証し、必要なサービスを提供します。この仕様で説明されているOAuth 2.0 for STUNを使用したサードパーティ認証は、NAT（TURN）[RFC5766]のリレーを使用したトラバーサルでも使用できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document uses the following abbreviations:
このドキュメントでは、次の略語を使用しています。
o WebRTC Server: A web server that supports WebRTC [WEBRTC].
o WebRTCサーバー：WebRTC [WEBRTC]をサポートするWebサーバー。
o Access Token: OAuth 2.0 access token.
o アクセストークン：OAuth 2.0アクセストークン。
o mac_key: The session key generated by the authorization server. This session key has a lifetime that corresponds to the lifetime of the access token, is generated by the authorization server, and is bound to the access token.
o mac_key：認証サーバーによって生成されたセッションキー。このセッションキーには、アクセストークンの有効期間に対応する有効期間があり、認証サーバーによって生成され、アクセストークンにバインドされます。
o kid: An ephemeral and unique key identifier. The kid also allows the resource server to select the appropriate keying material for decryption.
o kid：一時的な一意のキー識別子。また、子供はリソースサーバーが復号化に適切なキー情報を選択できるようにします。
o AS: Authorization server.
o AS：認証サーバー。
o RS: Resource server.
o RS：リソースサーバー。
Some sections in this specification show the WebRTC server as the authorization server and the client as the WebRTC client; however, WebRTC is intended to be used for illustrative purpose only.
この仕様の一部のセクションでは、WebRTCサーバーを承認サーバーとして示し、クライアントをWebRTCクライアントとして示しています。ただし、WebRTCは、例示のみを目的として使用することを目的としています。
The STUN client knows that it can use OAuth 2.0 with the target STUN server either through configuration or when it receives the new STUN attribute THIRD-PARTY-AUTHORIZATION in the error response with an error code of 401 (Unauthorized).
STUNクライアントは、構成を通じて、またはエラーコード401（Unauthorized）のエラー応答で新しいSTUN属性THIRD-PARTY-AUTHORIZATIONを受信したときに、ターゲットSTUNサーバーでOAuth 2.0を使用できることを認識しています。
This specification uses the token type 'Assertion' (a.k.a. self-contained token) described in [RFC6819] where all the information necessary to authenticate the validity of the token is contained within the token itself. This approach has the benefit of avoiding a protocol between the STUN server and the authorization server for token validation, thus reducing latency. The content of the token is opaque to the client. The client embeds the token within a STUN request sent to the STUN server. Once the STUN server has determined the token is valid, its services are offered for a determined period of time. The access token issued by the authorization server is explained in Section 6.2. OAuth 2.0 in [RFC6749] defines four grant types. This specification uses the OAuth 2.0 grant type 'Implicit' as explained in Section 1.3.2 of [RFC6749] where the client is issued an access token directly. The string 'stun' is defined by this specification for use as the OAuth scope parameter (see Section 3.3 of [RFC6749]) for the OAuth token.
この仕様では、[RFC6819]で説明されているトークンタイプ「アサーション」（自己完結型トークン）を使用しています。トークンの有効性を認証するために必要なすべての情報は、トークン自体に含まれています。このアプローチには、トークン検証のためにSTUNサーバーと承認サーバーの間のプロトコルを回避するという利点があり、レイテンシが短縮されます。トークンの内容はクライアントには不透明です。クライアントは、STUNサーバーに送信されたSTUNリクエスト内にトークンを埋め込みます。 STUNサーバーがトークンが有効であると判断すると、そのサービスが所定の期間提供されます。認可サーバーによって発行されたアクセストークンについては、セクション6.2で説明します。 [RFC6749]のOAuth 2.0は、4つの付与タイプを定義しています。この仕様では、クライアントに直接アクセストークンが発行される[RFC6749]のセクション1.3.2で説明されているように、OAuth 2.0付与タイプ「暗黙的」を使用します。文字列「stun」は、OAuthトークンのOAuthスコープパラメータ（[RFC6749]のセクション3.3を参照）として使用するためにこの仕様で定義されています。
The exact mechanism used by a client to obtain a token and other OAuth 2.0 parameters like token type, mac_key, token lifetime, and kid is outside the scope of this document. Appendix B provides an example deployment scenario of interaction between the client and authorization server to obtain a token and other OAuth 2.0 parameters.
トークンと、トークンタイプ、mac_key、トークンの有効期間、子供などの他のOAuth 2.0パラメータを取得するためにクライアントが使用する正確なメカニズムは、このドキュメントの範囲外です。付録Bは、トークンとその他のOAuth 2.0パラメーターを取得するためのクライアントと許可サーバー間の相互作用のデプロイメントシナリオの例を示しています。
Section 3.1 illustrates the use of OAuth 2.0 to achieve third-party authorization for TURN.
セクション3.1は、OAuth 2.0を使用してTURNのサードパーティ認証を実現する方法を示しています。
TURN, an extension to the STUN protocol, is often used to improve the connectivity of peer-to-peer (P2P) applications. TURN ensures that a connection can be established even when one or both sides are incapable of a direct P2P connection. However, as a relay service, it imposes a non-trivial cost on the service provider. Therefore, access to a TURN service is almost always access controlled. In order to achieve third-party authorization, a resource owner, e.g., a WebRTC server, authorizes a TURN client to access resources on the TURN server.
STUNプロトコルの拡張であるTURNは、ピアツーピア（P2P）アプリケーションの接続性を向上させるためによく使用されます。 TURNは、片側または両側が直接P2P接続に対応していない場合でも接続を確立できるようにします。ただし、リレーサービスとして、サービスプロバイダーに重要なコストがかかります。したがって、TURNサービスへのアクセスは、ほとんど常にアクセス制御されています。サードパーティ認証を実現するために、WebRTCサーバーなどのリソース所有者は、TURNクライアントがTURNサーバー上のリソースにアクセスすることを認証します。
In this example, a resource owner, i.e., a WebRTC server, authorizes a TURN client to access resources on a TURN server.
この例では、リソースの所有者、つまりWebRTCサーバーが、TURNクライアントがTURNサーバー上のリソースにアクセスすることを承認しています。
+----------------------+----------------------------+
| OAuth 2.0 | WebRTC |
+======================+============================+
| Client | WebRTC client |
+----------------------+----------------------------+
| Resource owner | WebRTC server |
+----------------------+----------------------------+
| Authorization server | Authorization server |
+----------------------+----------------------------+
| Resource server | TURN server |
+----------------------+----------------------------+
Figure 1: OAuth Terminology Mapped to WebRTC Terminology
図1：WebRTC用語にマッピングされたOAuth用語
Using the OAuth 2.0 authorization framework, a WebRTC client (third-party application) obtains limited access to a TURN server (resource server) on behalf of the WebRTC server (resource owner or authorization server). The WebRTC client requests access to resources controlled by the resource owner (WebRTC server) and hosted by the resource server (TURN server). The WebRTC client obtains the access token, lifetime, session key, and kid. The TURN client conveys the access token and other OAuth 2.0 parameters learned from the authorization server to the TURN server. The TURN server obtains the session key from the access token. The TURN server validates the token, computes the message integrity of the request, and takes appropriate action, i.e, permits the TURN client to create allocations. This is shown in an abstract way in Figure 2.
OAuth 2.0承認フレームワークを使用して、WebRTCクライアント（サードパーティアプリケーション）は、WebRTCサーバー（リソースの所有者または承認サーバー）に代わってTURNサーバー（リソースサーバー）への制限付きアクセスを取得します。 WebRTCクライアントは、リソース所有者（WebRTCサーバー）によって制御され、リソースサーバー（TURNサーバー）によってホストされるリソースへのアクセスを要求します。 WebRTCクライアントは、アクセストークン、ライフタイム、セッションキー、およびキッドを取得します。 TURNクライアントは、認証サーバーから学習したアクセストークンとその他のOAuth 2.0パラメーターをTURNサーバーに伝達します。 TURNサーバーは、アクセストークンからセッションキーを取得します。 TURNサーバーはトークンを検証し、リクエストのメッセージの整合性を計算し、適切なアクションを実行します。つまり、TURNクライアントが割り当てを作成することを許可します。これを図2に抽象的な方法で示します。
+---------------+
| +<******+
+------------->| Authorization | *
| | server | *
| +----------|(WebRTC server)| * AS-RS,
| | | | * AUTH keys
(1) | | +---------------+ * (0)
Access | | (2) *
Token | | Access Token *
request | | + *
| | Session Key *
| | *
| V V
+-------+---+ +-+----=-----+
| | (3) | |
| | TURN request + Access | |
| WebRTC | Token | TURN |
| client |---------------------->| server |
| (Alice) | Allocate response (4) | |
| |<----------------------| |
+-----------+ +------------+
User: Alice
****: Out-of-Band Long-Term Symmetric Key Establishment
Figure 2: Interactions
図2：相互作用
In the below figure, the TURN client sends an Allocate request to the TURN server without credentials. Since the TURN server requires that all requests be authenticated using OAuth 2.0, the TURN server rejects the request with a 401 (Unauthorized) error code and the STUN attribute THIRD-PARTY-AUTHORIZATION. The WebRTC client obtains an access token from the WebRTC server, provides the access token to the TURN client, and it tries again, this time including the access token in the Allocate request. This time, the TURN server validates the token, accepts the Allocate request, and returns an Allocate success response containing (among other things) the relayed transport address assigned to the allocation.
次の図では、TURNクライアントは資格情報なしでAllocateリクエストをTURNサーバーに送信します。 TURNサーバーはすべてのリクエストがOAuth 2.0を使用して認証されることを要求するので、TURNサーバーは401（Unauthorized）エラーコードとSTUN属性THIRD-PARTY-AUTHORIZATIONでリクエストを拒否します。 WebRTCクライアントはWebRTCサーバーからアクセストークンを取得し、そのアクセストークンをTURNクライアントに提供して、もう一度試行します。今回は、Allocateリクエストにアクセストークンを含めます。今回は、TURNサーバーがトークンを検証し、割り当て要求を受け入れ、割り当てに割り当てられた中継トランスポートアドレスを（とりわけ）含む割り当て成功応答を返します。
+-------------------+ +--------+ +---------+
| ......... TURN | | TURN | | WebRTC |
| .WebRTC . client | | | | |
| .client . | | server | | server |
| ......... | | | | |
+-------------------+ +--------+ +---------+
| | Allocate request | |
| |------------------------------------------>| |
| | | |
| | Allocate error response | |
| | (401 Unauthorized) | |
| |<------------------------------------------| |
| | THIRD-PARTY-AUTHORIZATION | |
| | | |
| | | |
| | HTTP request for token | |
|------------------------------------------------------------>|
| | HTTP response with token parameters | |
|<------------------------------------------------------------|
|OAuth 2.0 | |
attributes | |
|------>| | |
| | Allocate request ACCESS-TOKEN | |
| |------------------------------------------>| |
| | | |
| | Allocate success response | |
| |<------------------------------------------| |
| | TURN messages | |
| | ////// integrity protected ////// | |
| | ////// integrity protected ////// | |
| | ////// integrity protected ////// | |
Figure 3: TURN Third-Party Authorization
図3：TURNサードパーティ認証
A STUN client needs to know the authentication capability of the STUN server before deciding to use third-party authorization. A STUN client initially makes a request without any authorization. If the STUN server supports third-party authorization, it will return an error message indicating that the client can authorize to the STUN server using an OAuth 2.0 access token. The STUN server includes an ERROR-CODE attribute with a value of 401 (Unauthorized), a nonce value in a NONCE attribute, and a SOFTWARE attribute that gives information about the STUN server's software. The STUN server also includes the additional STUN attribute THIRD-PARTY-AUTHORIZATION, which signals the STUN client that the STUN server supports third-party authorization.
STUNクライアントは、サードパーティの承認の使用を決定する前に、STUNサーバーの認証機能を知っている必要があります。 STUNクライアントは、最初は許可なしに要求を行います。 STUNサーバーがサードパーティの認証をサポートしている場合、クライアントがOAuth 2.0アクセストークンを使用してSTUNサーバーに認証できることを示すエラーメッセージが返されます。 STUNサーバーには、値が401（無許可）のERROR-CODE属性、NONCE属性のnonce値、およびSTUNサーバーのソフトウェアに関する情報を提供するSOFTWARE属性が含まれています。 STUNサーバーには、追加のSTUN属性THIRD-PARTY-AUTHORIZATIONも含まれています。これは、STUNサーバーがサードパーティの承認をサポートしていることをSTUNクライアントに通知します。
Note: An implementation may choose to contact the authorization server to obtain a token even before it makes a STUN request, if it knows the server details beforehand. For example, once a client has learned that a STUN server supports third-party authorization from a authorization server, the client can obtain the token before making subsequent STUN requests.
注：実装は、事前にサーバーの詳細を知っている場合、STUN要求を行う前であっても、認証サーバーに接続してトークンを取得することを選択できます。たとえば、クライアントがSTUNサーバーが承認サーバーからのサードパーティの承認をサポートしていることを知ったら、クライアントは後続のSTUN要求を行う前にトークンを取得できます。
In this model, the STUN server would not authenticate the client itself but would rather verify whether the client knows the session key associated with a specific access token. An example of this approach can be found with the OAuth 2.0 Proof-of-Possession (PoP) Security Architecture [POP-ARCH]. The authorization server shares a long-term secret (K) with the STUN server. When the client requests an access token, the authorization server creates a fresh and unique session key (mac_key) and places it into the token encrypted with the long-term secret. Symmetric cryptography MUST be chosen to ensure that the size of the encrypted token is not large because usage of asymmetric cryptography will result in large encrypted tokens, which may not fit into a single STUN message.
このモデルでは、STUNサーバーはクライアント自体を認証せず、クライアントが特定のアクセストークンに関連付けられたセッションキーを知っているかどうかを確認します。このアプローチの例は、OAuth 2.0の所有証明（PoP）セキュリティアーキテクチャ[POP-ARCH]にあります。許可サーバーは、STUNサーバーと長期秘密（K）を共有します。クライアントがアクセストークンを要求すると、認証サーバーは新しい一意のセッションキー（mac_key）を作成し、それを長期秘密で暗号化されたトークンに配置します。非対称暗号化を使用すると、暗号化されたトークンが大きくなり、1つのSTUNメッセージに収まらない場合があるため、暗号化トークンのサイズが大きくならないように、対称暗号化を選択する必要があります。
The STUN server and authorization server can establish a long-term symmetric key (K) and a certain authenticated encryption algorithm, using an out-of-band mechanism. The STUN and authorization servers MUST establish K over an authenticated secure channel. If authenticated encryption with AES-CBC and HMAC-SHA (defined in [ENCRYPT]) is used, then the AS-RS and AUTH keys will be derived from K. The AS-RS key is used for encrypting the self-contained token, and the message integrity of the encrypted token is calculated using the AUTH key. If the Authenticated Encryption with Associated Data (AEAD) algorithm defined in [RFC5116] is used, then there is no need to generate the AUTH key, and the AS-RS key will have the same value as K.
STUNサーバーと承認サーバーは、アウトオブバンドメカニズムを使用して、長期対称キー（K）と特定の認証済み暗号化アルゴリズムを確立できます。 STUNおよび許可サーバーは、認証された安全なチャネルを介してKを確立する必要があります。 AES-CBCおよびHMAC-SHA（[ENCRYPT]で定義）で認証された暗号化が使用される場合、AS-RSおよびAUTHキーはKから派生します。AS-RSキーは自己完結型トークンの暗号化に使用されます。暗号化されたトークンのメッセージ整合性は、AUTHキーを使用して計算されます。 [RFC5116]で定義されている関連データ付き認証暗号化（AEAD）アルゴリズムを使用する場合、AUTHキーを生成する必要はなく、AS-RSキーはKと同じ値になります。
The procedure for establishment of the long-term symmetric key is outside the scope of this specification, and this specification does not mandate support of any given mechanism. Sections 4.1.1 and 4.1.2 show examples of mechanisms that can be used.
長期対称鍵を確立するための手順は、この仕様の範囲外であり、この仕様は、特定のメカニズムのサポートを義務付けていません。セクション4.1.1および4.1.2は、使用可能なメカニズムの例を示しています。
The STUN and AS servers could choose to use Representational State Transfer (REST) API over HTTPS to establish a long-term symmetric key. HTTPS MUST be used for data confidentiality, and TLS based on a client certificate MUST be used for mutual authentication. To retrieve a new long-term symmetric key, the STUN server makes an HTTP GET request to the authorization server, specifying STUN as the service to allocate the long-term symmetric keys for and specifying the name of the STUN server. The response is returned with content-type 'application/json' and consists of a JavaScript Object Notation (JSON) [RFC7159] object containing the long-term symmetric key.
STUNサーバーとASサーバーは、HTTPSを介してREST（Representational State Transfer）APIを使用して、長期対称キーを確立することを選択できます。データの機密保持にはHTTPSを使用する必要があり、相互認証にはクライアント証明書に基づくTLSを使用する必要があります。新しい長期対称キーを取得するために、STUNサーバーは認証サーバーにHTTP GET要求を発行し、長期対称キーを割り当てるサービスとしてSTUNを指定し、STUNサーバーの名前を指定します。応答はcontent-type 'application / json'で返され、長期対称キーを含むJavaScript Object Notation（JSON）[RFC7159]オブジェクトで構成されます。
Request
-------
service - specifies the desired service (TURN) name - STUN server name associated with the key
service-目的のサービス（TURN）名を指定します-キーに関連付けられたSTUNサーバー名
example:
GET https://www.example.com/.well-known/stun-key?service=stun
&name=turn1@example.com
Response
--------
k - long-term symmetric key exp - identifies the time after which the key expires
k-長期対称鍵exp-鍵の有効期限が切れるまでの時間を識別します
example:
{
"k" :
"ESIzRFVmd4iZABEiM0RVZgKn6WjLaTC1FXAghRMVTzkBGNaaN496523WIISKerLi",
"exp" : 1300819380,
"kid" :"22BIjxU93h/IgwEb"
"enc" : A256GCM
}
The authorization server must also signal kid to the STUN server, which will be used to select the appropriate keying material for decryption. The parameter 'k' is defined in Section 6.4.1 of [RFC7518], 'enc' is defined in Section 4.1.2 of [RFC7516], 'kid' is defined in Section 4.1.4 of [RFC7515], and 'exp' is defined in Section 4.1.4 of [RFC7519]. A256GCM and other authenticated encryption algorithms are defined in Section 5.1 of [RFC7518]. A STUN server and authorization server implementation MUST support A256GCM as the authenticated encryption algorithm.
認可サーバーはまた、STUNサーバーに子供に信号を送る必要があります。STUNサーバーは、復号化に適切なキー情報を選択するために使用されます。パラメータ「k」は[RFC7518]のセクション6.4.1で定義され、「enc」は[RFC7516]のセクション4.1.2で定義され、「kid」は[RFC7515]のセクション4.1.4で定義され、「exp 'は、[RFC7519]のセクション4.1.4で定義されています。 A256GCMおよびその他の認証済み暗号化アルゴリズムは、[RFC7518]のセクション5.1で定義されています。 STUNサーバーと承認サーバーの実装では、認証された暗号化アルゴリズムとしてA256GCMをサポートする必要があります。
If A256CBC-HS512 as defined in [RFC7518] is used, then the AS-RS and AUTH keys are derived from K using the mechanism explained in Section 5.2.2.1 of [RFC7518]. In this case, the AS-RS key length must be 256 bits and the AUTH key length must be 256 bits (Section 2.6 of [RFC4868]).
[RFC7518]で定義されているA256CBC-HS512が使用される場合、AS-RSおよびAUTHキーは、[RFC7518]のセクション5.2.2.1で説明されているメカニズムを使用してKから派生します。この場合、AS-RSキーの長さは256ビットで、AUTHキーの長さは256ビットでなければなりません（[RFC4868]のセクション2.6）。
The STUN and AS servers could be manually configured with a long-term symmetric key, an authenticated encryption algorithm, and kid.
STUNサーバーとASサーバーは、長期対称キー、認証された暗号化アルゴリズム、およびkidを使用して手動で構成できます。
Note: The mechanism specified in this section requires configuration to change the long-term symmetric key and/or authenticated encryption algorithm. Hence, a STUN server and authorization server implementation SHOULD support REST as explained in Section 4.1.1.
注：このセクションで指定するメカニズムでは、長期対称鍵や認証済み暗号化アルゴリズムを変更するための構成が必要です。したがって、STUNサーバーと承認サーバーの実装では、セクション4.1.1で説明されているRESTをサポートする必要があります（SHOULD）。
When a STUN server responds that third-party authorization is required, a STUN client re-attempts the request, this time including access token and kid values in the ACCESS-TOKEN and USERNAME STUN attributes. The STUN client includes a MESSAGE-INTEGRITY attribute as the last attribute in the message over the contents of the STUN message. The HMAC for the MESSAGE-INTEGRITY attribute is computed as described in Section 15.4 of [RFC5389] where the mac_key is used as the input key for the HMAC computation. The STUN client and server will use the mac_key to compute the message integrity and do not perform MD5 hash on the credentials.
STUNサーバーがサードパーティの認証が必要であると応答すると、STUNクライアントはリクエストを再試行します。今回は、ACCESS-TOKENおよびUSERNAME STUN属性にアクセストークンとキッドの値が含まれます。 STUNクライアントには、STUNメッセージの内容に対するメッセージの最後の属性としてMESSAGE-INTEGRITY属性が含まれています。 MESSAGE-INTEGRITY属性のHMACは、[RFC5389]のセクション15.4で説明されているように計算され、mac_keyがHMAC計算の入力キーとして使用されます。 STUNクライアントとサーバーは、mac_keyを使用してメッセージの整合性を計算し、資格情報に対してMD5ハッシュを実行しません。
The following new STUN attributes are introduced by this specification to accomplish third-party authorization.
この仕様では、サードパーティの承認を実現するために、次の新しいSTUN属性が導入されています。
This attribute is used by the STUN server to inform the client that it supports third-party authorization. This attribute value contains the STUN server name. The authorization server may have tie ups with multiple STUN servers and vice versa, so the client MUST provide the STUN server name to the authorization server so that it can select the appropriate keying material to generate the self-contained token. If the authorization server does not have tie up with the STUN server, then it returns an error to the client. If the client does not support or is not capable of doing third-party authorization, then it defaults to first-party authentication. The THIRD-PARTY-AUTHORIZATION attribute is a comprehension-optional attribute (see Section 15 from [RFC5389]). If the client is able to comprehend THIRD-PARTY-AUTHORIZATION, it MUST ensure that third-party authorization takes precedence over first-party authentication (as explained in Section 10 of [RFC5389]).
この属性は、サードパーティの認証をサポートしていることをクライアントに通知するために、STUNサーバーによって使用されます。この属性値には、STUNサーバー名が含まれています。承認サーバーは複数のSTUNサーバーと提携している場合があり、その逆の場合もあるので、クライアントは、STUNサーバー名を承認サーバーに提供して、自己完結型トークンを生成するための適切なキー情報を選択できるようにする必要があります。認可サーバーがSTUNサーバーと連携していない場合、クライアントにエラーが返されます。クライアントがサードパーティの承認をサポートしていないか、実行できない場合は、デフォルトでファーストパーティの認証が使用されます。 THIRD-PARTY-AUTHORIZATION属性はcomprehension-optional属性です（[RFC5389]のセクション15を参照）。クライアントがTHIRD-PARTY-AUTHORIZATIONを理解できる場合は、サードパーティの承認がファーストパーティの認証よりも優先されるようにする必要があります（[RFC5389]のセクション10で説明されています）。
The access token is issued by the authorization server. OAuth 2.0 does not impose any limitation on the length of the access token but if path MTU is unknown, then STUN messages over IPv4 would need to be less than 548 bytes (Section 7.1 of [RFC5389]). The access token length needs to be restricted to fit within the maximum STUN message size. Note that the self-contained token is opaque to the client, and the client MUST NOT examine the token. The ACCESS-TOKEN attribute is a comprehension-required attribute (see Section 15 from [RFC5389]).
アクセストークンは、認証サーバーによって発行されます。 OAuth 2.0はアクセストークンの長さに制限を課しませんが、パスMTUが不明な場合、IPv4上のSTUNメッセージは548バイト未満である必要があります（[RFC5389]のセクション7.1）。アクセストークンの長さは、最大のSTUNメッセージサイズに収まるように制限する必要があります。自己完結型トークンはクライアントに対して不透明であり、クライアントはトークンを検査してはならないことに注意してください。 ACCESS-TOKEN属性は内包が必要な属性です（[RFC5389]のセクション15を参照）。
The token is structured as follows:
トークンは次のように構成されています。
struct {
uint16_t nonce_length;
opaque nonce[nonce_length];
opaque {
uint16_t key_length;
opaque mac_key[key_length];
uint64_t timestamp;
uint32_t lifetime;
} encrypted_block;
} token;
Figure 4: Self-Contained Token Format
図4：自己完結型トークンの形式
Note: uintN_t means an unsigned integer of exactly N bits. Single-byte entities containing uninterpreted data are of type 'opaque'. All values in the token are stored in network byte order.
注：uintN_tは、正確にNビットの符号なし整数を意味します。未解釈のデータを含む1バイトエンティティのタイプは「不透明」です。トークンのすべての値は、ネットワークバイトオーダーで格納されます。
The fields are described below:
フィールドについて以下に説明します。
nonce_length: Length of the nonce field. The length of nonce for AEAD algorithms is explained in [RFC5116].
nonce_length：nonceフィールドの長さ。 AEADアルゴリズムのノンスの長さは、[RFC5116]で説明されています。
Nonce: Nonce (N) formation is explained in Section 3.2 of [RFC5116].
ノンス：ノンス（N）の形成については、[RFC5116]のセクション3.2で説明されています。
key_length: Length of the session key in octets. The key length of 160 bits MUST be supported (i.e., only the 160-bit key is used by HMAC-SHA-1 for message integrity of STUN messages). The key length facilitates the hash agility plan discussed in Section 16.3 of [RFC5389].
key_length：オクテット単位のセッションキーの長さ。 160ビットのキーの長さをサポートする必要があります（つまり、STUNメッセージのメッセージ整合性のためにHMAC-SHA-1が使用するのは160ビットのキーのみです）。キーの長さは、[RFC5389]のセクション16.3で説明されているハッシュアジリティ計画を容易にします。
mac_key: The session key generated by the authorization server.
mac_key：認証サーバーによって生成されたセッションキー。
timestamp: 64-bit unsigned integer field containing a timestamp. The value indicates the time since January 1, 1970, 00:00 UTC, by using a fixed-point format. In this format, the integer number of seconds is contained in the first 48 bits of the field, and the remaining 16 bits indicate the number of 1/64000 fractions of a second (Native format - Unix).
timestamp：タイムスタンプを含む64ビットの符号なし整数フィールド。この値は、固定小数点形式を使用して、1970年1月1日00:00 UTCからの時間を示します。この形式では、秒数の整数がフィールドの最初の48ビットに含まれ、残りの16ビットは1秒の1/64000の小数の数を示します（ネイティブ形式-Unix）。
lifetime: The lifetime of the access token, in seconds. For example, the value 3600 indicates one hour. The lifetime value MUST be greater than or equal to the 'expires_in' parameter defined in Section 4.2.2 of [RFC6749], otherwise the resource server could revoke the token, but the client would assume that the token has not expired and would not refresh the token.
lifetime：アクセストークンの有効期間（秒単位）。たとえば、値3600は1時間を示します。ライフタイム値は、[RFC6749]のセクション4.2.2で定義されている「expires_in」パラメータ以上である必要があります。そうでない場合、リソースサーバーはトークンを取り消すことができますが、クライアントはトークンの期限が切れておらず、更新されないものと想定しますトークン。
encrypted_block: The encrypted_block (P) is encrypted and authenticated using the long-term symmetric key established between the STUN server and the authorization server.
encrypted_block：encrypted_block（P）は、STUNサーバーと許可サーバーの間に確立された長期対称鍵を使用して暗号化および認証されます。
The AEAD encryption operation has four inputs: K, N, A, and P, as defined in Section 2.1 of [RFC5116], and there is a single output of ciphertext C or an indication that the requested encryption operation could not be performed.
[RFC5116]のセクション2.1で定義されているように、AEAD暗号化操作にはK、N、A、Pの4つの入力があり、暗号文Cの出力が1つ、または要求された暗号化操作を実行できなかったことを示します。
The associated data (A) MUST be the STUN server name. This ensures that the client does not use the same token to gain illegal access to other STUN servers provided by the same administrative domain, i.e., when multiple STUN servers in a single administrative domain share the same long-term symmetric key with an authorization server.
関連データ（A）はSTUNサーバー名でなければなりません。これにより、クライアントが同じトークンを使用して、同じ管理ドメインによって提供される他のSTUNサーバーに不正にアクセスすることがなくなります。つまり、単一の管理ドメイン内の複数のSTUNサーバーが許可サーバーと同じ長期対称キーを共有する場合です。
If authenticated encryption with AES-CBC and HMAC-SHA (explained in Section 2.1 of [ENCRYPT]) is used, then the encryption process is as illustrated below. The ciphertext consists of the string S, with the string T appended to it. Here, C and A denote ciphertext and the STUN server name, respectively. The octet string AL (Section 2.1 of [ENCRYPT]) is equal to the number of bits in A expressed as a 64-bit unsigned big-endian integer.
AES-CBCおよびHMAC-SHAを使用した認証済み暗号化（[ENCRYPT]のセクション2.1で説明）を使用する場合、暗号化プロセスは以下のようになります。暗号文は文字列Sで構成され、文字列Tが追加されます。ここで、CとAはそれぞれ暗号文とSTUNサーバー名を示します。オクテット文字列AL（[ENCRYPT]のセクション2.1）は、64ビットの符号なしビッグエンディアン整数として表されるAのビット数と同じです。
o AUTH = initial authentication key length octets of K,
o AUTH = Kの初期認証キー長オクテット、
o AS-RS = final encryption key length octets of K,
o AS-RS = Kの最終暗号化キー長オクテット、
o S = CBC-PKCS7-ENC(AS-RS, encrypted_block),
o S = CBC-PKCS7-ENC（AS-RS、encrypted_block）、
* The Initialization Vector is set to zero because the encrypted_block in each access token will not be identical and hence will not result in generation of identical ciphertext.
* 各アクセストークンのencrypted_blockは同一ではなく、したがって同一の暗号文が生成されないため、初期化ベクトルはゼロに設定されます。
o mac = MAC(AUTH, A || S || AL), o T = initial T_LEN octets of mac,
o mac = MAC（AUTH、A || S || AL）、o T = macの初期T_LENオクテット、
o C = S || T.
o C = S || T.
The entire token, i.e., the 'encrypted_block', is base64 encoded (see Section 4 of [RFC4648]), and the resulting access token is signaled to the client.
トークン全体、つまり「encrypted_block」はbase64でエンコードされ（[RFC4648]のセクション4を参照）、結果のアクセストークンがクライアントに通知されます。
The STUN server, on receiving a request with the ACCESS-TOKEN attribute, performs checks listed in Section 10.2.2 of [RFC5389] in addition to the following steps to verify that the access token is valid:
STUNサーバーは、ACCESS-TOKEN属性を含むリクエストを受信すると、[RFC5389]のセクション10.2.2に記載されているチェックに加えて、次の手順を実行して、アクセストークンが有効であることを確認します。
o The STUN server selects the keying material based on kid signaled in the USERNAME attribute.
o STUNサーバーは、USERNAME属性で通知されたkidに基づいて、キー情報を選択します。
o The AEAD decryption operation has four inputs: K, N, A, and C, as defined in Section 2.2 of [RFC5116]. The AEAD decryption algorithm has only a single output, either a plaintext or a special symbol FAIL that indicates that the inputs are not authentic. If the authenticated decrypt operation returns FAIL, then the STUN server rejects the request with an error response 401 (Unauthorized).
o [RFC5116]のセクション2.2で定義されているように、AEAD復号化操作にはK、N、A、Cの4つの入力があります。 AEAD復号化アルゴリズムには、出力が1つしかありません。平文か、入力が本物ではないことを示す特別な記号FAILのどちらかです。認証された復号化操作がFAILを返す場合、STUNサーバーはエラー応答401（Unauthorized）で要求を拒否します。
o If AES_CBC_HMAC_SHA2 is used, then the final T_LEN octets are stripped from C. It performs the verification of the token message integrity by calculating HMAC over the STUN server name, the encrypted portion in the self-contained token, and the AL using the AUTH key, and if the resulting value does not match the mac field in the self-contained token, then it rejects the request with an error response 401 (Unauthorized).
o AES_CBC_HMAC_SHA2が使用される場合、最後のT_LENオクテットはCから取り除かれます。これは、STUNサーバー名、自己完結型トークンの暗号化部分、およびAUTHキーを使用するALに対してHMACを計算することにより、トークンメッセージの整合性の検証を実行します。 、および結果の値が自己完結型トークンのmacフィールドと一致しない場合、エラー応答401（Unauthorized）で要求を拒否します。
o The STUN server obtains the mac_key by retrieving the content of the access token (which requires decryption of the self-contained token using the AS-RS key).
o STUNサーバーは、アクセストークンのコンテンツを取得することでmac_keyを取得します（AS-RSキーを使用して自己完結型トークンを復号化する必要があります）。
o The STUN server verifies that no replay took place by performing the following check:
o STUNサーバーは、次のチェックを実行して、再生が行われなかったことを確認します。
* The access token is accepted if the timestamp field (TS) in the self-contained token is shortly before the reception time of the STUN request (RDnew). The following formula is used:
* 自己完結型トークンのタイムスタンプフィールド（TS）がSTUNリクエストの受信時刻（RDnew）の少し前にある場合、アクセストークンは受け入れられます。次の式が使用されます。
lifetime + Delta > abs(RDnew - TS)
The RECOMMENDED value for the allowed Delta is 5 seconds. If the timestamp is NOT within the boundaries, then the STUN server discards the request with error response 401 (Unauthorized).
許可されたデルタの推奨値は5秒です。タイムスタンプが境界内にない場合、STUNサーバーはエラー応答401（Unauthorized）を使用して要求を破棄します。
o The STUN server uses the mac_key to compute the message integrity over the request, and if the resulting value does not match the contents of the MESSAGE-INTEGRITY attribute, then it rejects the request with an error response 401 (Unauthorized).
o STUNサーバーは、mac_keyを使用して、要求に対するメッセージの整合性を計算し、結果の値がMESSAGE-INTEGRITY属性の内容と一致しない場合、エラー応答401（無許可）で要求を拒否します。
o If all the checks pass, the STUN server continues to process the request.
o すべてのチェックに合格すると、STUNサーバーはリクエストの処理を続行します。
o Any response generated by the server MUST include the MESSAGE-INTEGRITY attribute, computed using the mac_key.
o サーバーが生成する応答には、mac_keyを使用して計算されたMESSAGE-INTEGRITY属性を含める必要があります。
If a STUN server receives an ACCESS-TOKEN attribute unexpectedly (because it had not previously sent out a THIRD-PARTY-AUTHORIZATION), it will respond with an error code of 420 (Unknown Attribute) as specified in Section 7.3.1 of [RFC5389].
STUNサーバーが予期せずACCESS-TOKEN属性を受信した場合（以前にTHIRD-PARTY-AUTHORIZATIONを送信していないため）、[RFC5389のセクション7.3.1で指定されているように、エラーコード420（不明な属性）で応答します]。
o The client looks for the MESSAGE-INTEGRITY attribute in the response. If MESSAGE-INTEGRITY is absent or the value computed for message integrity using mac_key does not match the contents of the MESSAGE-INTEGRITY attribute, then the response MUST be discarded.
o クライアントは、応答でMESSAGE-INTEGRITY属性を探します。 MESSAGE-INTEGRITYが存在しない場合、またはmac_keyを使用してメッセージの整合性について計算された値がMESSAGE-INTEGRITY属性の内容と一致しない場合は、応答を破棄する必要があります。
o If the access token expires, then the client MUST obtain a new token from the authorization server and use it for new STUN requests.
o アクセストークンの有効期限が切れた場合、クライアントは認証サーバーから新しいトークンを取得して、新しいSTUNリクエストに使用する必要があります。
Changes specific to TURN are listed below:
TURNに固有の変更を以下に示します。
o The access token can be reused for multiple Allocate requests to the same TURN server. The TURN client MUST include the ACCESS-TOKEN attribute only in Allocate and Refresh requests. Since the access token is valid for a specific period of time, the TURN server can cache it so that it can check if the access token in a new allocation request matches one of the cached tokens and avoids the need to decrypt the token.
o アクセストークンは、同じTURNサーバーへの複数の割り当て要求に再利用できます。 TURNクライアントは、割り当て要求と更新要求にのみACCESS-TOKEN属性を含める必要があります。アクセストークンは特定の期間有効であるため、TURNサーバーはそれをキャッシュして、新しい割り当て要求のアクセストークンがキャッシュされたトークンの1つと一致するかどうかを確認し、トークンを復号化する必要を回避できます。
o The lifetime provided by the TURN server in the Allocate and Refresh responses MUST be less than or equal to the lifetime of the token. It is RECOMMENDED that the TURN server calculate the maximum allowed lifetime value using the formula:
o 割り当ておよび更新応答でTURNサーバーによって提供される有効期間は、トークンの有効期間以下でなければなりません。 TURNサーバーが次の式を使用して最大許容ライフタイム値を計算することをお勧めします。
lifetime + Delta - abs(RDnew - TS)
The RECOMMENDED value for the allowed Delta is 5 seconds.
許可されたデルタの推奨値は5秒です。
o If the access token expires, then the client MUST obtain a new token from the authorization server and use it for new allocations. The client MUST use the new token to refresh existing allocations. This way, the client has to maintain only one token per TURN server.
o アクセストークンの有効期限が切れた場合、クライアントは認証サーバーから新しいトークンを取得して、新しい割り当てに使用する必要があります。クライアントは、新しいトークンを使用して既存の割り当てを更新する必要があります。このように、クライアントはTURNサーバーごとに1つのトークンのみを維持する必要があります。
The following operational considerations should be taken into account:
次の運用上の考慮事項を考慮する必要があります。
o Each authorization server should maintain the list of STUN servers for which it will grant tokens and the long-term secret shared with each of those STUN servers.
o 各認可サーバーは、トークンを付与するSTUNサーバーのリストと、それらの各STUNサーバーと共有する長期シークレットを維持する必要があります。
o If manual configuration (Section 4.1.2) is used to establish long-term symmetric keys, the necessary information, which includes long-term secret (K) and the authenticated encryption algorithm, has to be configured on each authorization server and STUN server for each kid. The client obtains the session key and HMAC algorithm from the authorization server in company with the token.
o 手動構成（セクション4.1.2）を使用して長期対称鍵を確立する場合、長期秘密（K）と認証済み暗号化アルゴリズムを含む必要な情報を、各許可サーバーとSTUNサーバーで構成する必要があります。それぞれの子供。クライアントは、トークンと一緒に会社の承認サーバーからセッションキーとHMACアルゴリズムを取得します。
o When a STUN client sends a request to get access to a particular STUN server (S), the authorization server must ensure that it selects the appropriate kid and access token depending on server S.
o STUNクライアントが特定のSTUNサーバー（S）にアクセスするためのリクエストを送信するとき、認証サーバーはサーバーSに応じて適切な子供とアクセストークンを選択することを確認する必要があります。
When OAuth 2.0 is used, the interaction between the client and the authorization server requires Transport Layer Security (TLS) with a ciphersuite offering confidentiality protection, and the guidance given in [RFC7525] must be followed to avoid attacks on TLS. The session key MUST NOT be transmitted in clear since this would completely destroy the security benefits of the proposed scheme. An attacker trying to replay the message with the ACCESS-TOKEN attribute can be mitigated by frequent changes of the nonce value as discussed in Section 10.2 of [RFC5389]. The client may know some (but not all) of the token fields encrypted with an unknown secret key, and the token can be subjected to known-plaintext attacks, but AES is secure against this attack.
OAuth 2.0を使用する場合、クライアントと承認サーバー間の相互作用には、機密保護を提供する暗号スイートを備えたトランスポート層セキュリティ（TLS）が必要です。TLSへの攻撃を回避するには、[RFC7525]で提供されているガイダンスに従う必要があります。セッションキーは、提案されたスキームのセキュリティ上の利点を完全に破壊するため、平文で送信してはなりません。 [RFC5389]のセクション10.2で説明されているように、ACCESS-TOKEN属性を使用してメッセージを再生しようとする攻撃者は、ナンス値を頻繁に変更することで緩和できます。クライアントは、未知の秘密鍵で暗号化されたトークンフィールドの一部（すべてではない）を知っている場合があり、トークンは既知の平文攻撃を受ける可能性がありますが、AESはこの攻撃に対して安全です。
An attacker may remove the THIRD-PARTY-AUTHORIZATION STUN attribute from the error message forcing the client to pick first-party authentication; this attack may be mitigated by opting for TLS [RFC5246] or Datagram Transport Layer Security (DTLS) [RFC6347] as a transport protocol for STUN, as defined in [RFC5389]and [RFC7350].
攻撃者は、クライアントにファーストパーティ認証を選択させるエラーメッセージからTHIRD-PARTY-AUTHORIZATION STUN属性を削除する可能性があります。この攻撃は、[RFC5389]と[RFC7350]で定義されているように、STUNのトランスポートプロトコルとしてTLS [RFC5246]またはデータグラムトランスポート層セキュリティ（DTLS）[RFC6347]を選択することで軽減できます。
Threat mitigation discussed in Section 5 of [POP-ARCH] and security considerations in [RFC5389] are to be taken into account.
[POP-ARCH]のセクション5で説明されている脅威の軽減と[RFC5389]のセキュリティに関する考慮事項が考慮されます。
This document defines the THIRD-PARTY-AUTHORIZATION STUN attribute, described in Section 6. IANA has allocated the comprehension-optional codepoint 0x802E for this attribute.
このドキュメントでは、セクション6で説明されているTHIRD-PARTY-AUTHORIZATION STUN属性を定義しています。IANAは、この属性に内包オプションのコードポイント0x802Eを割り当てています。
This document defines the ACCESS-TOKEN STUN attribute, described in Section 6. IANA has allocated the comprehension-required codepoint 0x001B for this attribute.
このドキュメントでは、セクション6で説明されているACCESS-TOKEN STUN属性を定義しています。IANAは、この属性に必要なコードポイント0x001Bを割り当てています。
This memo registers the 'stun-key' well-known URI in the Well-Known URIs registry as defined by [RFC5785].
このメモは[stun-key]の既知のURIを[RFC5785]で定義されている既知のURIレジストリに登録します。
URI suffix: stun-key
URIサフィックス：stun-key
Change controller: IETF
コントローラの変更：IETF
Specification document(s): This RFC
仕様書：このRFC
Related information: None
関連情報：なし
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<http://www.rfc-editor.org/info/rfc4648>。
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007, <http://www.rfc-editor.org/info/rfc4868>.
[RFC4868]ケリー、S。、およびS.フランケル、「IPsecでのHMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512の使用」、RFC 4868、DOI 10.17487 / RFC4868、2007年5月、<http： //www.rfc-editor.org/info/rfc4868>。
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <http://www.rfc-editor.org/info/rfc5116>.
[RFC5116] McGrew、D。、「認証された暗号化のためのインターフェースとアルゴリズム」、RFC 5116、DOI 10.17487 / RFC5116、2008年1月、<http://www.rfc-editor.org/info/rfc5116>。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <http://www.rfc-editor.org/info/rfc5389>.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NAT用セッショントラバーサルユーティリティ（STUN）」、RFC 5389、DOI 10.17487 / RFC5389、2008年10月、<http：// www.rfc-editor.org/info/rfc5389>。
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <http://www.rfc-editor.org/info/rfc6749>.
[RFC6749] Hardt、D。、編、「The OAuth 2.0 Authorization Framework」、RFC 6749、DOI 10.17487 / RFC6749、2012年10月、<http://www.rfc-editor.org/info/rfc6749>。
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <http://www.rfc-editor.org/info/rfc7518>.
[RFC7518]ジョーンズ、M。、「JSON Web Algorithms（JWA）」、RFC 7518、DOI 10.17487 / RFC7518、2015年5月、<http://www.rfc-editor.org/info/rfc7518>。
[ENCRYPT] McGrew, D., Foley, J., and K. Paterson, "Authenticated Encryption with AES-CBC and HMAC-SHA", Work in Progress, draft-mcgrew-aead-aes-cbc-hmac-sha2-05, July 2014.
[暗号化] McGrew、D.、Foley、J。、およびK. Paterson、「AES-CBCおよびHMAC-SHAによる認証済み暗号化」、作業中、draft-mcgrew-aead-aes-cbc-hmac-sha2-05 、2014年7月。
[POP-ARCH] Hunt, P., Richer, J., Mills, W., Mishra, P., and H. Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security Architecture", Work in Progress, draft-ietf-oauth-pop-architecture-02, July 2015.
[POP-ARCH] Hunt、P.、Richer、J.、Mills、W.、Mishra、P。、およびH. Tschofenig、「OAuth 2.0 Proof-of-Possession（PoP）Security Architecture」、Work in Progress、draft -ietf-oauth-pop-architecture-02、2015年7月。
[POP-KEY-DIST] Bradley, J., Hunt, P., Jones, M., and H. Tschofenig, "OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution", Work in Progress, draft-ietf-oauth-pop-key-distribution-01, March 2015.
[POP-KEY-DIST] Bradley、J.、Hunt、P.、Jones、M。、およびH. Tschofenig、「OAuth 2.0 Proof-of-Possession：Authorization Server to Client Key Distribution」、Work in Progress、draft- ietf-oauth-pop-key-distribution-01、2015年3月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, DOI 10.17487/RFC5766, April 2010, <http://www.rfc-editor.org/info/rfc5766>.
[RFC5766] Mahy、R.、Matthews、P.、J。Rosenberg、「NAT（TURN）のリレーを使用したトラバーサル：NATのセッショントラバーサルユーティリティへのリレー拡張（STUN）」、RFC 5766、DOI 10.17487 / RFC5766、4月2010、<http://www.rfc-editor.org/info/rfc5766>。
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, <http://www.rfc-editor.org/info/rfc5785>.
[RFC5785]ノッティンガム、M。およびE.ハマーラハブ、「Defining Well-Known Uniform Resource Identifiers（URIs）」、RFC 5785、DOI 10.17487 / RFC5785、2010年4月、<http://www.rfc-editor.org / info / rfc5785>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<http://www.rfc-editor.org/info/rfc6347>。
[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", RFC 6819, DOI 10.17487/RFC6819, January 2013, <http://www.rfc-editor.org/info/rfc6819>.
[RFC6819] Lodderstedt、T.、Ed。、McGloin、M。、およびP. Hunt、「OAuth 2.0脅威モデルとセキュリティの考慮事項」、RFC 6819、DOI 10.17487 / RFC6819、2013年1月、<http：//www.rfc -editor.org/info/rfc6819>。
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]ブレイ、T。、編、「JavaScriptオブジェクト表記（JSON）データ交換フォーマット」、RFC 7159、DOI 10.17487 / RFC7159、2014年3月、<http://www.rfc-editor.org/info/ rfc7159>。
[RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350, August 2014, <http://www.rfc-editor.org/info/rfc7350>.
[RFC7350] Petit-Huguenin、M。、およびG. Salgueiro、「NATのセッショントラバーサルユーティリティ（STUN）のトランスポートとしてのデータグラムトランスポート層セキュリティ（DTLS）」、RFC 7350、DOI 10.17487 / RFC7350、2014年8月、<http：/ /www.rfc-editor.org/info/rfc7350>。
[RFC7376] Reddy, T., Ravindranath, R., Perumal, M., and A. Yegin, "Problems with Session Traversal Utilities for NAT (STUN) Long-Term Authentication for Traversal Using Relays around NAT (TURN)", RFC 7376, DOI 10.17487/RFC7376, September 2014, <http://www.rfc-editor.org/info/rfc7376>.
[RFC7376] Reddy、T.、Ravindranath、R.、Perumal、M。、およびA. Yegin、「NATのセッショントラバーサルユーティリティの問題（STUN）NATのリレーを使用したトラバーサルの長期認証（TURN）」、RFC 7376、DOI 10.17487 / RFC7376、2014年9月、<http://www.rfc-editor.org/info/rfc7376>。
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <http://www.rfc-editor.org/info/rfc7515>.
[RFC7515]ジョーンズ、M。、ブラッドリー、J。、およびN.崎村、「JSON Web Signature（JWS）」、RFC 7515、DOI 10.17487 / RFC7515、2015年5月、<http://www.rfc-editor.org / info / rfc7515>。
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, <http://www.rfc-editor.org/info/rfc7516>.
[RFC7516]ジョーンズ、M。およびJ.ヒルデブランド、「JSON Web Encryption（JWE）」、RFC 7516、DOI 10.17487 / RFC7516、2015年5月、<http://www.rfc-editor.org/info/rfc7516>。
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <http://www.rfc-editor.org/info/rfc7519>.
[RFC7519]ジョーンズ、M。、ブラッドリー、J.、N。崎村、「JSON Web Token（JWT）」、RFC 7519、DOI 10.17487 / RFC7519、2015年5月、<http://www.rfc-editor.org / info / rfc7519>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<http://www.rfc-editor.org/info/rfc7525>。
[STUN] Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, D., Mahy, R., and P. Matthews, "Session Traversal Utilities for NAT (STUN)", Work in Progress, draft-ietf-tram-stunbis-04, March 2015.
[STUN] Petit-Huguenin、M.、Salgueiro、G.、Rosenberg、J.、Wing、D.、Mahy、R。、およびP. Matthews、「NATのセッショントラバーサルユーティリティ（STUN）」、作業中、 draft-ietf-tram-stunbis-04、2015年3月。
[WEBRTC] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", Work in Progress, draft-ietf-rtcweb-overview-14, June 2015.
[WEBRTC] Alvestrand、H。、「Overview：Real Time Protocols for Browser-based Applications」、Work in Progress、draft-ietf-rtcweb-overview-14、June 2015。
Input data (same for all samples below):
入力データ（以下のすべてのサンプルで同じ）：
//STUN SERVER NAME
server_name = "blackdow.carleon.gov";
//Shared key between AS and RS
// ASとRSの間の共有キー
long_term_key = \x48\x47\x6b\x6a\x33\x32\x4b\x4a\x47\x69\x75\x79 \x30\x39\x38\x73\x64\x66\x61\x71\x62\x4e\x6a\x4f \x69\x61\x7a\x37\x31\x39\x32\x33
long_term_key = \ x48 \ x47 \ x6b \ x6a \ x33 \ x32 \ x4b \ x4a \ x47 \ x69 \ x75 \ x79 \ x30 \ x39 \ x38 \ x73 \ x64 \ x66 \ x61 \ x71 \ x62 \ x4e \ x6a \ x4f \ x69 \ x61 \ x7a \ x37 \ x31 \ x39 \ x32 \ x33
//MAC key of the session (included in the token) mac_key = \x5a\x6b\x73\x6a\x70\x77\x65\x6f\x69\x78\x58\x6d\x76\x6e \x36\x37\x35\x33\x34\x6d;
//セッションのMACキー（トークンに含まれる）mac_key = \ x5a \ x6b \ x73 \ x6a \ x70 \ x77 \ x65 \ x6f \ x69 \ x78 \ x58 \ x6d \ x76 \ x6e \ x36 \ x37 \ x35 \ x33 \ x34 \ x6d;
//length of the MAC key
mac_key_length = 20;
//The timestamp field in the token
token_timestamp = 92470300704768;
//The lifetime of the token
token_lifetime = 3600;
//nonce for AEAD
aead_nonce = \x68\x34\x6a\x33\x6b\x32\x6c\x32\x6e\x34\x62\x35;
Samples:
サンプル：
1) token encryption algorithm = AEAD_AES_256_GCM
1）トークン暗号化アルゴリズム= AEAD_AES_256_GCM
Encrypted token (64 bytes = 2 + 12 + 34 + 16) =
\x00\x0c\x68\x34\x6a\x33\x6b\x32\x6c\x32\x6e\x34\x62 \x35\x61\x7e\xf1\x34\xa3\xd5\xe4\x4e\x9a\x19\xcc\x7d \xc1\x04\xb0\xc0\x3d\x03\xb2\xa5\x51\xd8\xfd\xf5\xcd \x3b\x6d\xca\x6f\x10\xcf\xb7\x7e\x5b\x2d\xde\xc8\x4d \x29\x3a\x5c\x50\x49\x93\x59\xf0\xc2\xe2\x6f\x76
\ x00 \ x0c \ x68 \ x34 \ x6a \ x33 \ x6b \ x32 \ x6c \ x32 \ x6e \ x34 \ x62 \ x35 \ x61 \ x7e \ xf1 \ x34 \ xa3 \ xd5 \ xe4 \ x4e \ x9a \ x19 \ xcc \ x7d \ xc1 \ x04 \ xb0 \ xc0 \ x3d \ x03 \ xb2 \ xa5 \ x51 \ xd8 \ xfd \ xf5 \ xcd \ x3b \ x6d \ xca \ x6f \ x10 \ xcf \ xb7 \ x7e \ x5b \ x2d \ xde \ xc8 \ x4d \ x29 \ x3a \ x5c \ x50 \ x49 \ x93 \ x59 \ xf0 \ xc2 \ xe2 \ x6f \ x76
2) token encryption algorithm = AEAD_AES_128_GCM
2）トークン暗号化アルゴリズム= AEAD_AES_128_GCM
Encrypted token (64 bytes = 2 + 12 + 34 + 16) =
\x00\x0c\x68\x34\x6a\x33\x6b\x32\x6c\x32\x6e\x34\x62 \x35\x7f\xb9\xe9\x9f\x08\x27\xbe\x3d\xf1\xe1\xbd\x65 \x14\x93\xd3\x03\x1d\x36\xdf\x57\x07\x97\x84\xae\xe5 \xea\xcb\x65\xfa\xd4\xf2\x7f\xab\x1a\x3f\x97\x97\x4b \x69\xf8\x51\xb2\x4b\xf5\xaf\x09\xed\xa3\x57\xe0
\ x00 \ x0c \ x68 \ x34 \ x6a \ x33 \ x6b \ x32 \ x6c \ x32 \ x6e \ x34 \ x62 \ x35 \ x7f \ xb9 \ xe9 \ x9f \ x08 \ x27 \ xbe \ x3d \ xf1 \ xe1 \ xbd \ x65 \ x14 \ x93 \ xd3 \ x03 \ x1d \ x36 \ xdf \ x57 \ x07 \ x97 \ x84 \ xae \ xe5 \ xea \ xcb \ x65 \ xfa \ xd4 \ xf2 \ x7f \ xab \ x1a \ x3f \ x97 \ x97 \ x4b \ x69 \ xf8 \ x51 \ xb2 \ x4b \ xf5 \ xaf \ x09 \ xed \ xa3 \ x57 \ xe0
Note: [1] After EVP_EncryptFinal_ex encrypts the final data, EVP_CIPHER_CTX_ctrl must be called to append the authentication tag to the ciphertext. //EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_AEAD_GET_TAG, taglen, tag);
注：[1] EVP_EncryptFinal_exが最終データを暗号化した後、EVP_CIPHER_CTX_ctrlを呼び出して、暗号文に認証タグを追加する必要があります。 // EVP_CIPHER_CTX_ctrl（ctx、EVP_CTRL_AEAD_GET_TAG、taglen、tag）;
[2] EVP_CIPHER_CTX_ctrl must be invoked to set the authentication tag before calling EVP_DecryptFinal. //EVP_CIPHER_CTX_ctrl (&ctx, EVP_CTRL_GCM_SET_TAG, taglen, tag);
[2] EVP_CIPHER_CTX_ctrlを呼び出して認証タグを設定してから、EVP_DecryptFinalを呼び出す必要があります。 // EVP_CIPHER_CTX_ctrl（＆ctx、EVP_CTRL_GCM_SET_TAG、taglen、tag）;
Figure 5: Sample Tickets
図5：チケットの例
The client makes an HTTP request to an authorization server to obtain a token that can be used to avail itself of STUN services. The STUN token is returned in JSON syntax [RFC7159], along with other OAuth 2.0 parameters like token type, key, token lifetime, and kid as defined in [POP-KEY-DIST].
クライアントは、認証サーバーにHTTPリクエストを送信して、STUNサービスを利用するために使用できるトークンを取得します。 STUNトークンは、[POP-KEY-DIST]で定義されているトークンタイプ、キー、トークンの有効期間、キッドなどの他のOAuth 2.0パラメータとともに、JSON構文[RFC7159]で返されます。
+-------------------+ +--------+ +---------+
| ......... STUN | | STUN | | WebRTC |
| .WebRTC . client | | | | |
| .client . | | server | | server |
| ......... | | | | |
+-------------------+ +--------+ +---------+
| | STUN request | |
| |------------------------------------------>| |
| | | |
| | STUN error response | |
| | (401 Unauthorized) | |
| |<------------------------------------------| |
| | THIRD-PARTY-AUTHORIZATION | |
| | | |
| | | |
| | HTTP request for token | |
|------------------------------------------------------------>|
| | HTTP response with token parameters | |
|<------------------------------------------------------------|
|OAuth 2.0 | |
attributes | |
|------>| | |
| | STUN request with ACCESS-TOKEN | |
| |------------------------------------------>| |
| | | |
| | STUN success response | |
| |<------------------------------------------| |
| | STUN messages | |
| | ////// integrity protected ////// | |
| | ////// integrity protected ////// | |
| | ////// integrity protected ////// | |
Figure 6: STUN Third-Party Authorization
図6：STUNサードパーティ認証
[POP-KEY-DIST] describes the interaction between the client and the authorization server. For example, the client learns the STUN server name "stun1@example.com" from the THIRD-PARTY-AUTHORIZATION attribute value and makes the following HTTP request for the access token using TLS (with extra line breaks for display purposes only):
[POP-KEY-DIST]は、クライアントと認証サーバー間の相互作用を記述します。たとえば、クライアントはTHIRD-PARTY-AUTHORIZATION属性値からSTUNサーバー名 "stun1@example.com"を学習し、TLSを使用してアクセストークンに対して次のHTTPリクエストを発行します（表示目的でのみ改行を追加します）。
HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
aud=stun1@example.com
timestamp=1361471629
grant_type=implicit
token_type=pop
alg=HMAC-SHA-256-128
Figure 7: Request
図7：リクエスト
[STUN] supports hash agility and accomplishes this agility by computing message integrity using both HMAC-SHA-1 and HMAC-SHA-256-128. The client signals the algorithm supported by it to the authorization server in the 'alg' parameter defined in [POP-KEY-DIST]. The authorization server determines the length of the mac_key based on the HMAC algorithm conveyed by the client. If the client supports both HMAC-SHA-1 and HMAC-SHA-256-128, then it signals HMAC-SHA-256-128 to the authorization server, gets a 256-bit key from the authorization server, and calculates a 160-bit key for HMAC-SHA-1 using SHA1 and taking the 256-bit key as input.
[STUN]はハッシュの俊敏性をサポートし、HMAC-SHA-1とHMAC-SHA-256-128の両方を使用してメッセージの整合性を計算することにより、この俊敏性を実現します。クライアントは、[POP-KEY-DIST]で定義された「alg」パラメーターで、クライアントがサポートするアルゴリズムを許可サーバーに通知します。許可サーバーは、クライアントから伝達されたHMACアルゴリズムに基づいてmac_keyの長さを決定します。クライアントがHMAC-SHA-1とHMAC-SHA-256-128の両方をサポートしている場合、クライアントはHMAC-SHA-256-128を承認サーバーに送信し、承認サーバーから256ビットのキーを取得し、160- SHA1を使用し、256ビットキーを入力として使用するHMAC-SHA-1のビットキー。
If the client is authorized, then the authorization server issues an access token. An example of a successful response:
クライアントが認証されると、認証サーバーがアクセストークンを発行します。成功した応答の例：
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"access_token":
"U2FsdGVkX18qJK/kkWmRcnfHglrVTJSpS6yU32kmHmOrfGyI3m1gQj1jRPsr0uBb
HctuycAgsfRX7nJW2BdukGyKMXSiNGNnBzigkAofP6+Z3vkJ1Q5pWbfSRroOkWBn",
"token_type":"pop",
"expires_in":1800,
"kid":"22BIjxU93h/IgwEb",
"key":"v51N62OM65kyMvfTI08O"
"alg":HMAC-SHA-256-128
}
Figure 8: Response
図8：応答
Acknowledgements
謝辞
The authors would like to thank Dan Wing, Pal Martinsen, Oleg Moskalenko, Charles Eckel, Spencer Dawkins, Hannes Tschofenig, Yaron Sheffer, Tom Taylor, Christer Holmberg, Pete Resnick, Kathleen Moriarty, Richard Barnes, Stephen Farrell, Alissa Cooper, and Rich Salz for comments and review. The authors would like to give special thanks to Brandon Williams for his help.
著者は、ダンウイング、パルマルティンセン、オレグモスカレンコ、チャールズエッケル、スペンサードーキンス、ハネスツコフェニグ、ヤロンシェファー、トムテイラー、クリスターホルムバーグ、ピートレズニック、キャスリーンモリアーティ、リチャードバーンズ、スティーブンファレル、アリッサクーパー、およびリッチに感謝します。コメントとレビューのためのザルツ。著者は彼の助けのためにブランドンウィリアムズに特に感謝したいと思います。
Thanks to Oleg Moskalenko for providing token samples in Appendix A.
付録Aでトークンのサンプルを提供してくれたOleg Moskalenkoに感謝します。
Authors' Addresses
著者のアドレス
Tirumaleswar Reddy Cisco Systems, Inc. Cessna Business Park, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India Email: tireddy@cisco.com
Tirumaleswar Reddy Cisco Systems、Inc. Cessna Business Park、Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore、Karnataka 560103 Indiaメール：tireddy@cisco.com
Prashanth Patil Cisco Systems, Inc. Bangalore India Email: praspati@cisco.com
Prashanth Patil Cisco Systems、Inc. Bangalore Indiaメール：praspati@cisco.com
Ram Mohan Ravindranath Cisco Systems, Inc. Cessna Business Park, Kadabeesanahalli Village, Varthur Hobli, Sarjapur-Marathahalli Outer Ring Road Bangalore, Karnataka 560103 India Email: rmohanr@cisco.com
Ram Mohan Ravindranath Cisco Systems、Inc. Cessna Business Park、Kadabeesanahalli Village、Varthur Hobli、Sarjapur-Marathahalli Outer Ring Road Bangalore、Karnataka 560103 Indiaメール：rmohanr@cisco.com
Justin Uberti Google 747 6th Ave S. Kirkland, WA 98033 United States Email: justin@uberti.name
Justin Uberti Google 747 6th Ave S. Kirkland、WA 98033アメリカ合衆国メール：justin@uberti.name