[要約] RFC 5746は、Transport Layer Security (TLS) プロトコルにおける再交渉プロセスのセキュリティを強化するために提案された。この文書は、再交渉時にクライアントとサーバー間で一意の識別子を交換することにより、中間者攻撃による情報漏洩のリスクを軽減する「再交渉指示拡張」を導入しています。この拡張機能は、TLSのセキュリティを向上させるために重要であり、特にセキュアなトランザクションが必要な金融機関やオンラインショッピングサイトなどで利用されます。関連するRFCには、TLSの基本を定義するRFC 5246や、その他のセキュリティ強化を提案するRFC 5747などがあります。
Internet Engineering Task Force (IETF) E. Rescorla
Request for Comments: 5746 RTFM, Inc.
Updates: 5246, 4366, 4347, 4346, 2246 M. Ray
Category: Standards Track S. Dispensa
ISSN: 2070-1721 PhoneFactor
N. Oskov
Microsoft
February 2010
Transport Layer Security (TLS) Renegotiation Indication Extension
輸送層のセキュリティ（TLS）再交渉の表示拡張
Abstract
概要
Secure Socket Layer (SSL) and Transport Layer Security (TLS) renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client. The server treats the client's initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data. This specification defines a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack.
セキュアソケットレイヤー（SSL）およびトランスポートレイヤーセキュリティ（TLS）再交渉は、攻撃者がターゲットサーバーとTLS接続を形成し、選択したコンテンツを注入し、クライアントからの新しいTLS接続にスプライスする攻撃に対して脆弱です。サーバーは、クライアントの最初のTLSハンドシェイクを再交渉として扱うため、攻撃者が送信する最初のデータは、後続のクライアントデータと同じエンティティからのものであると考えています。この仕様は、実行中のTLS接続に再移行を結び付けるためのTLS拡張を定義しているため、この攻撃を防ぎます。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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）の製品です。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/rfc5746.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5746で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Secure Renegotiation Definition .................................4
3.1. Additional Connection State ................................4
3.2. Extension Definition .......................................5
3.3. Renegotiation Protection Request Signaling Cipher
Suite Value ................................................6
3.4. Client Behavior: Initial Handshake .........................6
3.5. Client Behavior: Secure Renegotiation ......................7
3.6. Server Behavior: Initial Handshake .........................7
3.7. Server Behavior: Secure Renegotiation ......................8
4. Backward Compatibility ..........................................9
4.1. Client Considerations ......................................9
4.2. Client Behavior: Legacy (Insecure) Renegotiation ..........10
4.3. Server Considerations .....................................10
4.4. Server Behavior: Legacy (Insecure) Renegotiation ..........11
4.5. SSLv3 .....................................................11
5. Security Considerations ........................................12
6. IANA Considerations ............................................13
7. Acknowledgements ...............................................13
8. References .....................................................13
8.1. Normative References ......................................13
8.2. Informative References ....................................13
TLS [RFC5246] allows either the client or the server to initiate renegotiation -- a new handshake that establishes new cryptographic parameters. Unfortunately, although the new handshake is carried out using the cryptographic parameters established by the original handshake, there is no cryptographic binding between the two. This creates the opportunity for an attack in which the attacker who can intercept a client's transport layer connection can inject traffic of his own as a prefix to the client's interaction with the server. One form of this attack [Ray09] proceeds as shown below:
TLS [RFC5246]により、クライアントまたはサーバーのいずれかが再交渉を開始できます。これは、新しい暗号化パラメーターを確立する新しい握手です。残念ながら、元の握手によって確立された暗号化パラメーターを使用して新しい握手は実行されますが、2つの間に暗号化の結合はありません。これにより、クライアントのトランスポートレイヤー接続を傍受できる攻撃者が、クライアントのサーバーとの相互作用の接頭辞として自分のトラフィックを挿入できる攻撃の機会が生まれます。この攻撃の1つの形式[Ray09]は、以下に示すように進行します。
Client Attacker Server
------ ------- ------
<----------- Handshake ---------->
<======= Initial Traffic ========>
<-------------------------- Handshake ============================>
<======================== Client Traffic ==========================>
To start the attack, the attacker forms a TLS connection to the server (perhaps in response to an initial intercepted connection from the client). He then sends any traffic of his choice to the server. This may involve multiple requests and responses at the application layer, or may simply be a partial application layer request intended to prefix the client's data. This traffic is shown with == to indicate it is encrypted. He then allows the client's TLS handshake to proceed with the server. The handshake is in the clear to the attacker but encrypted over the attacker's TLS connection to the server. Once the handshake has completed, the client communicates with the server over the newly established security parameters with the server. The attacker cannot read this traffic, but the server believes that the initial traffic to and from the attacker is the same as that to and from the client.
攻撃を開始するために、攻撃者はサーバーへのTLS接続を形成します（おそらく、クライアントからの初期のインターセプトされた接続に応じて）。その後、選択したトラフィックをサーバーに送信します。これには、アプリケーションレイヤーでの複数のリクエストと応答が含まれる場合があります。または、クライアントのデータをプレフィックスすることを目的とした部分的なアプリケーションレイヤー要求である場合があります。このトラフィックは、暗号化されていることを示すために==で表示されます。次に、クライアントのTLSハンドシェイクがサーバーを進めることを許可します。握手は攻撃者にとっては明確ですが、サーバーへの攻撃者のTLS接続の上に暗号化されています。握手が完了すると、クライアントは、サーバーを使用して新しく確立されたセキュリティパラメーターを介してサーバーと通信します。攻撃者はこのトラフィックを読み取ることができませんが、サーバーは、攻撃者との間の初期トラフィックはクライアントとの間でそれと同じであると考えています。
If certificate-based client authentication is used, the server will see a stream of bytes where the initial bytes are protected but unauthenticated by TLS and subsequent bytes are authenticated by TLS and bound to the client's certificate. In some protocols (notably HTTPS), no distinction is made between pre- and post-authentication stages and the bytes are handled uniformly, resulting in the server believing that the initial traffic corresponds to the authenticated client identity. Even without certificate-based authentication, a variety of attacks may be possible in which the attacker convinces the server to accept data from it as data from the client. For instance, if HTTPS [RFC2818] is in use with HTTP cookies [RFC2965], the attacker may be able to generate a request of his choice validated by the client's cookie.
証明書ベースのクライアント認証を使用すると、サーバーは初期バイトが保護されているが、TLSによって認知されていないバイトのストリームが表示され、その後のバイトはTLSによって認証され、クライアントの証明書にバインドされます。一部のプロトコル（特にHTTPS）では、認証前と後期後の段階を区別することはできず、バイトは均一に処理され、初期トラフィックが認証されたクライアントIDに対応すると信じてサーバーが均一に処理されます。証明書ベースの認証がなくても、攻撃者がサーバーからデータをクライアントからのデータとして受け入れるよう説得するさまざまな攻撃が可能になる場合があります。たとえば、HTTPS [RFC2818]がHTTP Cookie [RFC2965]で使用されている場合、攻撃者はクライアントのCookieによって検証された選択の要求を生成できる可能性があります。
Some protocols -- such as IMAP or SMTP -- have more explicit transitions between authenticated and unauthenticated phases and require that the protocol state machine be partly or fully reset at such transitions. If strictly followed, these rules may limit the effect of attacks. Unfortunately, there is no requirement for state machine resets at TLS renegotiation, and thus there is still a potential window of vulnerability, for instance, by prefixing a command that writes to an area visible by the attacker with a command by the client that includes his password, thus making the client's password visible to the attacker (note that this precise attack does not work with challenge-response authentication schemes, but other attacks may be possible). Similar attacks are available with SMTP, and in fact do not necessarily require the attacker to have an account on the target server.
IMAPやSMTPなどの一部のプロトコルには、認証されたフェーズと非認証フェーズの間により明確な遷移があり、プロトコル状態マシンがそのような遷移で部分的または完全にリセットする必要があります。厳密に従うと、これらのルールは攻撃の影響を制限する可能性があります。残念ながら、TLS再交渉での状態マシンリセットの要件はありません。したがって、たとえば、攻撃者が彼を含むコマンドを使用して攻撃者が見える領域に書き込むコマンドに書き込むコマンドを接頭することにより、脆弱性の潜在的なウィンドウがまだあります。したがって、パスワードは、クライアントのパスワードを攻撃者に見えるようにします（この正確な攻撃は、チャレンジ応答認証スキームでは機能しないことに注意してくださいが、他の攻撃は可能かもしれません）。同様の攻撃がSMTPで利用可能であり、実際、攻撃者がターゲットサーバーにアカウントを取得する必要はありません。
It is important to note that in both cases these attacks are possible because the client sends unsolicited authentication information without requiring any specific data from the server over the TLS connection. Protocols that require a round trip to the server over TLS before the client sends sensitive information are likely to be less vulnerable.
どちらの場合も、これらの攻撃が可能であることに注意することが重要です。なぜなら、クライアントはTLS接続を介してサーバーから特定のデータを必要とせずに承認されていない認証情報を送信するためです。クライアントが機密情報を送信する前にTLSを介してサーバーへの往復を必要とするプロトコルは、脆弱性が低くなる可能性があります。
These attacks can be prevented by cryptographically binding renegotiation handshakes to the enclosing TLS cryptographic parameters, thus allowing the server to differentiate renegotiation from initial negotiation, as well as preventing renegotiations from being spliced in between connections. An attempt by an attacker to inject himself as described above will result in a mismatch of the cryptographic binding and can thus be detected. The data used in the extension is similar to, but not the same as, the data used in the tls-unique and/or tls-unique-for-telnet channel bindings described in [TLS-CHANNEL-BINDINGS]; however, this extension is not a general-purpose RFC 5056 [RFC5056] channel binding facility.
これらの攻撃は、暗号化されたTLS暗号化パラメーターへの暗号化的に結合した再交渉の握手を防ぐことができ、したがって、サーバーが最初の交渉と再交渉を区別できるようになり、再交渉が接続の間にスプライスされるのを防ぐことができます。上記のように攻撃者が自分自身を注入しようとする試みは、暗号化結合の不一致をもたらし、したがって検出することができます。拡張機能で使用されるデータは、[TLS-Channel-Bindings]で説明されているTLS-Uniqueおよび/またはTLS-Unique-for-Telnetチャネルバインディングで使用されるデータと類似していますが、同じではありません。ただし、この拡張機能は、汎用RFC 5056 [RFC5056]チャネル結合施設ではありません。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Both client and server need to store three additional values for each TLS connection state (see RFC 5246, Section 6.1). Note that these values are specific to connection (not a TLS session cache entry).
クライアントとサーバーの両方が、各TLS接続状態に3つの追加値を保存する必要があります（RFC 5246、セクション6.1を参照）。これらの値は接続に固有であることに注意してください（TLSセッションのキャッシュエントリではありません）。
o a "secure_renegotiation" flag, indicating whether secure renegotiation is in use for this connection.
o 「Secure_Renegotiation」フラグ。この接続に安全な再交渉が使用されているかどうかを示します。
o "client_verify_data": the verify_data from the Finished message sent by the client on the immediately previous handshake. For currently defined TLS versions and cipher suites, this will be a 12-byte value; for SSLv3, this will be a 36-byte value.
o 「client_verify_data」：直前の握手でクライアントが送信した完成したメッセージからのverify_data。現在定義されているTLSバージョンと暗号スイートの場合、これは12バイトの値になります。SSLV3の場合、これは36バイトの値になります。
o "server_verify_data": the verify_data from the Finished message sent by the server on the immediately previous handshake.
o "server_verify_data"：前回のハンドシェイクでサーバーから送信された完成したメッセージからのverify_data。
This document defines a new TLS extension, "renegotiation_info" (with extension type 0xff01), which contains a cryptographic binding to the enclosing TLS connection (if any) for which the renegotiation is being performed. The "extension data" field of this extension contains a "RenegotiationInfo" structure:
このドキュメントでは、新しいTLS拡張機能「Renegotiation_Info」（拡張型タイプ0xFF01）を定義します。これには、再交渉が実行されている囲いTLS接続（存在する場合）への暗号化結合が含まれています。この拡張機能の「拡張データ」フィールドには、「ReNegotiationInfo」構造が含まれています。
struct {
opaque renegotiated_connection<0..255>;
} RenegotiationInfo;
The contents of this extension are specified as follows.
この拡張機能の内容は、次のように指定されています。
o If this is the initial handshake for a connection, then the "renegotiated_connection" field is of zero length in both the ClientHello and the ServerHello. Thus, the entire encoding of the extension is ff 01 00 01 00. The first two octets represent the extension type, the third and fourth octets the length of the extension itself, and the final octet the zero length byte for the "renegotiated_connection" field.
o これが接続の最初の握手である場合、「Renegotiated_Connection」フィールドは、clienthelloとserverhelloの両方で長さがゼロです。したがって、拡張のエンコード全体はFF 01 00 01 00です。最初の2つのオクテットは、拡張タイプ、3番目と4番目のオクテットを拡張自体の長さ、最後のオクテットは「RENEGOTIED_CONNECTION」フィールドのゼロ長バイトを表します。。
o For ClientHellos that are renegotiating, this field contains the "client_verify_data" specified in Section 3.1.
o 再交渉しているclienthellosの場合、このフィールドにはセクション3.1で指定された「client_verify_data」が含まれています。
o For ServerHellos that are renegotiating, this field contains the concatenation of client_verify_data and server_verify_data. For current versions of TLS, this will be a 24-byte value (for SSLv3, it will be a 72-byte value).
o 再交渉しているServerHellosの場合、このフィールドにはclient_verify_dataとserver_verify_dataの連結が含まれています。TLSの現在のバージョンの場合、これは24バイトの値になります（SSLV3の場合、72バイト値になります）。
This extension also can be used with Datagram TLS (DTLS) [RFC4347]. Although, for editorial simplicity, this document refers to TLS, all requirements in this document apply equally to DTLS.
この拡張機能は、Datagram TLS（DTLS）[RFC4347]で使用することもできます。編集上の単純さのために、このドキュメントはTLSを指しますが、このドキュメントのすべての要件はDTLに等しく適用されます。
Both the SSLv3 and TLS 1.0/TLS 1.1 specifications require implementations to ignore data following the ClientHello (i.e., extensions) if they do not understand it. However, some SSLv3 and TLS 1.0 implementations incorrectly fail the handshake in such a case. This means that clients that offer the "renegotiation_info" extension may encounter handshake failures. In order to enhance compatibility with such servers, this document defines a second signaling mechanism via a special Signaling Cipher Suite Value (SCSV) "TLS_EMPTY_RENEGOTIATION_INFO_SCSV", with code point {0x00, 0xFF}. This SCSV is not a true cipher suite (it does not correspond to any valid set of algorithms) and cannot be negotiated. Instead, it has the same semantics as an empty "renegotiation_info" extension, as described in the following sections. Because SSLv3 and TLS implementations reliably ignore unknown cipher suites, the SCSV may be safely sent to any server. The SCSV can also be included in the SSLv2 backward compatible CLIENT-HELLO (see Appendix E.2 of [RFC5246]).
SSLV3とTLS 1.0/TLS 1.1仕様の両方で、クライアントヘロ（つまり、拡張機能）に続くデータを無視するための実装が必要です。ただし、一部のSSLV3およびTLS 1.0の実装は、そのような場合の握手を間違って失敗させます。これは、「Renegotiation_Info」拡張機能を提供するクライアントが握手の失敗に遭遇する可能性があることを意味します。このようなサーバーとの互換性を高めるために、このドキュメントは、コードポイント{0x00、0xff}を使用して、特別なシグナリング暗号スイート値（SCSV） "TLS_EMPTY_RENEGOTIATION_INFO_SCSV"を介して2番目のシグナル伝達メカニズムを定義します。このSCSVは、真の暗号スイートではなく（有効なアルゴリズムセットに対応していません）、交渉できません。代わりに、次のセクションで説明されているように、空の「Renegotiation_Info」拡張機能と同じセマンティクスがあります。SSLV3およびTLS実装は不明な暗号スイートを確実に無視するため、SCSVは任意のサーバーに安全に送信される場合があります。SCSVは、SSLV2後方互換クライアントヘロにも含めることができます（[RFC5246]の付録E.2を参照）。
Note: a minimal client that does not support renegotiation at all can simply use the SCSV in all initial handshakes. The rules in the following sections will cause any compliant server to abort the handshake when it sees an apparent attempt at renegotiation by such a client.
注：再交渉をまったくサポートしていない最小限のクライアントは、すべての初期握手でSCSVを単純に使用できます。次のセクションのルールは、そのようなクライアントによる再交渉の明らかな試みが見られたときに、任意の準拠サーバーが握手を中止します。
Note that this section and Section 3.5 apply to both full handshakes and session resumption handshakes.
このセクションとセクション3.5は、完全な握手とセッション再開の両方の握手の両方に適用されることに注意してください。
o The client MUST include either an empty "renegotiation_info" extension, or the TLS_EMPTY_RENEGOTIATION_INFO_SCSV signaling cipher suite value in the ClientHello. Including both is NOT RECOMMENDED.
o クライアントは、空の「Renegotiation_Info」拡張機能を含める必要があります。または、clienthelloにTLS_EMPTY_RENEGOTIATION_INFO_SCSVシグナリングCipherスイート値を含める必要があります。両方を含めることは推奨されません。
o When a ServerHello is received, the client MUST check if it includes the "renegotiation_info" extension:
o ServerHelloを受信したとき、クライアントは「Renegotiation_Info」拡張機能を含むかどうかを確認する必要があります。
* If the extension is not present, the server does not support secure renegotiation; set secure_renegotiation flag to FALSE. In this case, some clients may want to terminate the handshake instead of continuing; see Section 4.1 for discussion.
* 拡張機能が存在しない場合、サーバーは安全な再交渉をサポートしていません。secure_renegotiationフラグをfalseに設定します。この場合、一部のクライアントは、継続する代わりに握手を終了したい場合があります。ディスカッションについては、セクション4.1を参照してください。
* If the extension is present, set the secure_renegotiation flag to TRUE. The client MUST then verify that the length of the "renegotiated_connection" field is zero, and if it is not, MUST abort the handshake (by sending a fatal handshake_failure alert).
* 拡張機能が存在する場合は、secure_renegotiationフラグをtrueに設定します。次に、クライアントは、「Renegotiated_Connection」フィールドの長さがゼロであることを確認する必要があります。
Note: later in Section 3, "abort the handshake" is used as shorthand for "send a fatal handshake_failure alert and terminate the connection".
注：セクション3の後半では、「ハンドシェイクを中止」は、「致命的なハンドシェイク_failureアラートを送信して接続を終了する」ために速記として使用されます。
o When the handshake has completed, the client needs to save the client_verify_data and server_verify_data values for future use.
o ハンドシェイクが完了したら、クライアントは将来の使用のためにclient_verify_dataとserver_verify_data値を保存する必要があります。
This text applies if the connection's "secure_renegotiation" flag is set to TRUE (if it is set to FALSE, see Section 4.2).
このテキストは、接続の「secure_renegotiation」フラグがtrueに設定されている場合に適用されます（falseに設定されている場合は、セクション4.2を参照）。
o The client MUST include the "renegotiation_info" extension in the ClientHello, containing the saved client_verify_data. The SCSV MUST NOT be included.
o クライアントは、保存されたclient_verify_dataを含むclienthelloに「renegotiation_info」拡張機能を含める必要があります。SCSVを含めてはなりません。
o When a ServerHello is received, the client MUST verify that the "renegotiation_info" extension is present; if it is not, the client MUST abort the handshake.
o ServerHelloを受信したとき、クライアントは「Renegotiation_Info」拡張機能が存在することを確認する必要があります。そうでない場合、クライアントは握手を中止する必要があります。
o The client MUST then verify that the first half of the "renegotiated_connection" field is equal to the saved client_verify_data value, and the second half is equal to the saved server_verify_data value. If they are not, the client MUST abort the handshake.
o 次に、クライアントは、「Renegotiated_Connection」フィールドの前半が保存されたclient_verify_data値に等しく、後半が保存されたserver_verify_data値に等しいことを確認する必要があります。そうでない場合、クライアントは握手を中止する必要があります。
o When the handshake has completed, the client needs to save the new client_verify_data and server_verify_data values.
o ハンドシェイクが完了したら、クライアントは新しいclient_verify_dataとserver_verify_data値を保存する必要があります。
Note that this section and Section 3.7 apply to both full handshakes and session-resumption handshakes.
このセクションとセクション3.7は、完全なハンドシェイクとセッションの再開の両方の握手の両方に適用されることに注意してください。
o When a ClientHello is received, the server MUST check if it includes the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV. If it does, set the secure_renegotiation flag to TRUE.
o clienthelloを受信したとき、サーバーはtls_empty_renegotiation_info_scsv scsvを含むかどうかを確認する必要があります。もしそうなら、secure_renegotiationフラグをtrueに設定します。
o The server MUST check if the "renegotiation_info" extension is included in the ClientHello. If the extension is present, set secure_renegotiation flag to TRUE. The server MUST then verify that the length of the "renegotiated_connection" field is zero, and if it is not, MUST abort the handshake.
o サーバーは、「Renegotiation_Info」拡張機能がClientHelloに含まれているかどうかを確認する必要があります。拡張機能が存在する場合は、secure_renegotiationフラグをtrueに設定します。次に、サーバーは、「Renegotiated_Connection」フィールドの長さがゼロであり、そうでない場合は握手を中止する必要があることを確認する必要があります。
o If neither the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV nor the "renegotiation_info" extension was included, set the secure_renegotiation flag to FALSE. In this case, some servers may want to terminate the handshake instead of continuing; see Section 4.3 for discussion.
o tls_empty_renegotiation_info_scsv scsvまたは「renegotiation_info」拡張機能が含まれていない場合、secure_renegotiationフラグをfalseに設定します。この場合、一部のサーバーは、継続する代わりに握手を終了することをお勧めします。ディスカッションについては、セクション4.3を参照してください。
o If the secure_renegotiation flag is set to TRUE, the server MUST include an empty "renegotiation_info" extension in the ServerHello message.
o secure_renegotiationフラグがtrueに設定されている場合、サーバーにはserverhelloメッセージに空の「renegotiation_info」拡張子を含める必要があります。
o When the handshake has completed, the server needs to save the client_verify_data and server_verify_data values for future use.
o ハンドシェイクが完了したら、サーバーは将来の使用のためにclient_verify_dataとserver_verify_data値を保存する必要があります。
TLS servers implementing this specification MUST ignore any unknown extensions offered by the client and they MUST accept version numbers higher than their highest version number and negotiate the highest common version. These two requirements reiterate preexisting requirements in RFC 5246 and are merely stated here in the interest of forward compatibility.
この仕様を実装するTLSサーバーは、クライアントが提供する未知の拡張機能を無視する必要があり、最高版の数値よりも高いバージョン番号を受け入れ、最高の一般バージョンをネゴシエートする必要があります。これらの2つの要件は、RFC 5246の既存の要件を繰り返し繰り返しており、先進的な互換性のためにここで述べられているだけです。
Note that sending a "renegotiation_info" extension in response to a ClientHello containing only the SCSV is an explicit exception to the prohibition in RFC 5246, Section 7.4.1.4, on the server sending unsolicited extensions and is only allowed because the client is signaling its willingness to receive the extension via the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV. TLS implementations MUST continue to comply with Section 7.4.1.4 for all other extensions.
SCSVのみを含むクライアントヘロに応じて「Renegotiation_Info」拡張機能を送信することは、RFC 5246、セクション7.4.1.4の禁止の明示的な例外であることに注意してください。tls_empty_renegotiation_info_scsv scsvを介して拡張機能を受信します。TLSの実装は、他のすべての拡張機能について、引き続きセクション7.4.1.4に準拠する必要があります。
This text applies if the connection's "secure_renegotiation" flag is set to TRUE (if it is set to FALSE, see Section 4.4).
このテキストは、接続の「secure_renegotiation」フラグがtrueに設定されている場合に適用されます（falseに設定されている場合は、セクション4.4を参照）。
o When a ClientHello is received, the server MUST verify that it does not contain the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV. If the SCSV is present, the server MUST abort the handshake.
o ClientHelloを受信したとき、サーバーはTLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSVが含まれていないことを確認する必要があります。SCSVが存在する場合、サーバーは握手を中止する必要があります。
o The server MUST verify that the "renegotiation_info" extension is present; if it is not, the server MUST abort the handshake.
o サーバーは、「Renegotiation_Info」拡張機能が存在することを確認する必要があります。そうでない場合、サーバーは握手を中止する必要があります。
o The server MUST verify that the value of the "renegotiated_connection" field is equal to the saved client_verify_data value; if it is not, the server MUST abort the handshake.
o サーバーは、「Renegotiated_Connection」フィールドの値が保存されたclient_verify_data値に等しいことを確認する必要があります。そうでない場合、サーバーは握手を中止する必要があります。
o The server MUST include a "renegotiation_info" extension containing the saved client_verify_data and server_verify_data in the ServerHello.
o サーバーには、serverhelloに保存されたclient_verify_dataとserver_verify_dataを含む「renegotiation_info」拡張機能を含める必要があります。
o When the handshake has completed, the server needs to save the new client_verify_data and server_verify_data values.
o ハンドシェイクが完了したら、サーバーは新しいclient_verify_dataとserver_verify_data値を保存する必要があります。
Existing implementations that do not support this extension are widely deployed and, in general, must interoperate with newer implementations that do support it. This section describes considerations for backward compatible interoperation.
この拡張機能をサポートしていない既存の実装は広く展開されており、一般に、それをサポートする新しい実装と相互操作する必要があります。このセクションでは、後方互換の相互操作に関する考慮事項について説明します。
If a client offers the "renegotiation_info" extension or the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV and the server does not reply with "renegotiation_info" in the ServerHello, then this indicates that the server does not support secure renegotiation. Because some attacks (see Section 1) look like a single handshake to the client, the client cannot determine whether or not the connection is under attack. Note, however, that merely because the server does not acknowledge the extension does not mean that it is vulnerable; it might choose to reject all renegotiations and simply not signal it. However, it is not possible for the client to determine purely via TLS mechanisms whether or not this is the case.
クライアントが「Renegotiation_Info」拡張子またはTLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSVを提供し、サーバーがServerHelloの「Renegotiation_Info」で返信しない場合、これはサーバーが安全な再交渉をサポートしていないことを示します。一部の攻撃（セクション1を参照）は、クライアントにとって単一の握手のように見えるため、クライアントは接続が攻撃を受けているかどうかを判断できません。ただし、サーバーが拡張機能を認めていないという理由だけで、拡張機能が脆弱であることを意味するわけではありません。すべての再交渉を拒否することを選択し、単に合図しないことを選択するかもしれません。ただし、これが当てはまるかどうかにかかわらず、クライアントがTLSメカニズムを介して純粋に決定することはできません。
If clients wish to ensure that such attacks are impossible, they need to terminate the connection immediately upon failure to receive the extension without completing the handshake. Such clients MUST generate a fatal "handshake_failure" alert prior to terminating the connection. However, it is expected that many TLS servers that do not support renegotiation (and thus are not vulnerable) will not support this extension either, so in general, clients that implement this behavior will encounter interoperability problems. There is no set of client behaviors that will guarantee security and achieve maximum interoperability during the transition period. Clients need to choose one or the other preference when dealing with potentially un-upgraded servers.
クライアントがそのような攻撃が不可能であることを確認したい場合、握手を完了せずに拡張機能を受け取らなかった後、すぐに接続を終了する必要があります。このようなクライアントは、接続を終了する前に、致命的な「handshake_failure」アラートを生成する必要があります。ただし、再交渉をサポートしていない（したがって脆弱ではない）多くのTLSサーバーもこの拡張機能をサポートしないことが期待されているため、一般に、この動作を実装するクライアントは相互運用性の問題に遭遇します。セキュリティを保証し、移行期間中に最大の相互運用性を達成するクライアントの動作のセットはありません。クライアントは、潜在的にアップグレードされていないサーバーを扱う際に、いずれかを選択する必要があります。
This text applies if the connection's "secure_renegotiation" flag is set to FALSE.
このテキストは、接続の「secure_renegotiation」フラグがfalsに設定されている場合に適用されます。
It is possible that un-upgraded servers will request that the client renegotiate. It is RECOMMENDED that clients refuse this renegotiation request. Clients that do so MUST respond to such requests with a "no_renegotiation" alert (RFC 5246 requires this alert to be at the "warning" level). It is possible that the apparently un-upgraded server is in fact an attacker who is then allowing the client to renegotiate with a different, legitimate, upgraded server. If clients nevertheless choose to renegotiate, they MUST behave as described below.
アップグレードされていないサーバーが、クライアントが再交渉することを要求する可能性があります。クライアントがこの再交渉のリクエストを拒否することをお勧めします。「NO_RENEGOTIATION」アラート（RFC 5246では、このようなリクエストに応答する必要があります（RFC 5246では、このアラートが「警告」レベルにあることが必要です）。明らかに非アップグレードされたサーバーは、実際には攻撃者であり、クライアントが別の正当なアップグレードされたサーバーで再交渉できるようにする可能性があります。それにもかかわらず、クライアントは再交渉を選択した場合、以下に説明するように振る舞う必要があります。
Clients that choose to renegotiate MUST provide either the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV or "renegotiation_info" in their ClientHello. In a legitimate renegotiation with an un-upgraded server, that server should ignore both of these signals. However, if the server (incorrectly) fails to ignore extensions, sending the "renegotiation_info" extension may cause a handshake failure. Thus, it is permitted, though NOT RECOMMENDED, for the client to simply send the SCSV. This is the only situation in which clients are permitted to not send the "renegotiation_info" extension in a ClientHello that is used for renegotiation.
再交渉を選択するクライアントは、clienthelloでtls_empty_renegotiation_info_scsv scsvまたは "renegotiation_info"を提供する必要があります。UNアップグレードされたサーバーを使用した正当な再交渉では、そのサーバーはこれらの両方の信号を無視する必要があります。ただし、サーバーが（誤って）拡張機能を無視できない場合、「Renegotiation_Info」拡張機能を送信すると、ハンドシェイク障害が発生する場合があります。したがって、クライアントがSCSVを単純に送信することは推奨されませんが、推奨されませんが、許可されています。これは、クライアントが再交渉に使用されるクライアントヘロで「Renegotiation_Info」拡張機能を送信しないことを許可される唯一の状況です。
Note that in the case of a downgrade attack, if this is an initial handshake from the server's perspective, then use of the SCSV from the client precludes detection of this attack by the server (if this is a renegotiation from the server's perspective, then it will detect the attack). However, the attack will be detected by the client when the server sends an empty "renegotiation_info" extension and the client is expecting one containing the previous verify_data. By contrast, if the client sends the "renegotiation_info" extension, then the server will immediately detect the attack.
ダウングレード攻撃の場合、これがサーバーの観点からの最初の握手である場合、クライアントからのSCSVの使用は、サーバーによるこの攻撃の検出を妨げることに注意してください（これがサーバーの観点からの再交渉である場合、それから攻撃を検出します）。ただし、サーバーが空の「Renegotiation_Info」拡張機能を送信すると、クライアントが攻撃が検出され、クライアントは以前のverify_dataを含むものを期待しています。対照的に、クライアントが「Renegotiation_Info」拡張機能を送信すると、サーバーはすぐに攻撃を検出します。
When the ServerHello is received, the client MUST verify that it does not contain the "renegotiation_info" extension. If it does, the client MUST abort the handshake. (Because the server has already indicated it does not support secure renegotiation, the only way that this can happen is if the server is broken or there is an attack.)
ServerHelloが受信されたとき、クライアントは「Renegotiation_Info」拡張子が含まれていないことを確認する必要があります。もしそうなら、クライアントは握手を中止する必要があります。（サーバーはすでに安全な再交渉をサポートしていないことをすでに示しているため、これが起こる唯一の方法は、サーバーが壊れているか攻撃がある場合です。）
If the client does not offer the "renegotiation_info" extension or the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV, then this indicates that the client does not support secure renegotiation. Although the attack described in Section 1 looks like two handshakes to the server, other attacks may be possible in which the renegotiation is seen only by the client. If servers wish to ensure that such attacks are impossible, they need to terminate the connection immediately upon failure to negotiate the use of secure renegotiation. Servers that do choose to allow connections from unpatched clients can still prevent the attack described in Section 1 by refusing to renegotiate over those connections.
クライアントが「Renegotiation_Info」拡張機能またはTLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSVを提供していない場合、これはクライアントが安全な再交渉をサポートしていないことを示します。セクション1で説明されている攻撃は、サーバーに対する2つの握手のように見えますが、再交渉がクライアントのみが見られる他の攻撃が可能になる場合があります。サーバーがそのような攻撃が不可能であることを確認したい場合は、安全な再交渉の使用を交渉できないとすぐに接続を終了する必要があります。未満のクライアントからの接続を許可するサーバーは、それらの接続に対する再交渉を拒否することにより、セクション1に記載されている攻撃を防ぐことができます。
In order to enable clients to probe, even servers that do not support renegotiation MUST implement the minimal version of the extension described in this document for initial handshakes, thus signaling that they have been upgraded.
クライアントがプローブを可能にするために、再交渉をサポートしていないサーバーでさえ、このドキュメントで説明されている拡張機能の最小バージョンを最初のハンドシェイクのために実装する必要があり、したがって、それらがアップグレードされたことを示しています。
This text applies if the connection's "secure_renegotiation" flag is set to FALSE.
このテキストは、接続の「secure_renegotiation」フラグがfalsに設定されている場合に適用されます。
It is RECOMMENDED that servers not permit legacy renegotiation. If servers nevertheless do permit it, they MUST follow the requirements in this section.
サーバーがレガシー再交渉を許可しないことをお勧めします。それでもサーバーが許可している場合、このセクションの要件に従う必要があります。
o When a ClientHello is received, the server MUST verify that it does not contain the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV. If the SCSV is present, the server MUST abort the handshake.
o ClientHelloを受信したとき、サーバーはTLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSVが含まれていないことを確認する必要があります。SCSVが存在する場合、サーバーは握手を中止する必要があります。
o The server MUST verify that the "renegotiation_info" extension is not present; if it is, the server MUST abort the handshake.
o サーバーは、「Renegotiation_Info」拡張機能が存在しないことを確認する必要があります。もしそうなら、サーバーは握手を中止する必要があります。
While SSLv3 is not a protocol under IETF change control (see [SSLv3]), it was the original basis for TLS and most TLS implementations also support SSLv3. The IETF encourages SSLv3 implementations to adopt the "renegotiation_info" extension and SCSV as defined in this document. The semantics of the SCSV and extension are identical to TLS stacks except for the size of the verify_data values, which are 36 bytes long each. Note that this will require adding at least minimal extension processing to such stacks. Clients that support SSLv3 and offer secure renegotiation (either via SCSV or "renegotiation_info") MUST accept the "renegotiation_info" extension from the server, even if the server version is {0x03, 0x00}, and behave as described in this specification. TLS servers that support secure renegotiation and support SSLv3 MUST accept SCSV or the "renegotiation_info" extension and respond as described in this specification even if the offered client version is {0x03, 0x00}. SSLv3 does not define the "no_renegotiation" alert (and does not offer a way to indicate a refusal to renegotiate at a "warning" level). SSLv3 clients that refuse renegotiation SHOULD use a fatal handshake_failure alert.
SSLV3はIETF変更制御の下でのプロトコルではありませんが（[SSLV3]を参照）、TLSの元の基礎であり、ほとんどのTLS実装もSSLV3をサポートしています。IETFは、このドキュメントで定義されているように、SSLV3の実装が「Renegotiation_Info」拡張機能とSCSVを採用することを奨励しています。SCSVと拡張のセマンティクスは、それぞれ36バイトのVerify_Data値のサイズを除き、TLSスタックと同一です。これには、少なくとも最小限の拡張処理をそのようなスタックに追加する必要があることに注意してください。SSLV3をサポートし、安全な再交渉を提供するクライアント（SCSVまたは「Renegotiation_Info」のいずれか）は、サーバーバージョンが{0x03、0x00}であっても、サーバーからの「Renegotiation_Info」拡張機能を受け入れ、この仕様に記載されているように行動する必要があります。安全な再交渉をサポートし、SSLV3をサポートするTLSサーバーは、SCSVまたは「Renegotiation_Info」拡張機能を受け入れ、提供されたクライアントバージョンが{0x03、0x00}であっても、この仕様で説明されているように応答する必要があります。SSLV3は、「NO_RENEGOTIATION」アラートを定義しません（また、「警告」レベルで再交渉を拒否することを示す方法を提供しません）。再交渉を拒否するSSLV3クライアントは、致命的なHandshake_Failureアラートを使用する必要があります。
The extension described in this document prevents an attack on TLS. If this extension is not used, TLS renegotiation is subject to an attack in which the attacker can inject their own conversation with the TLS server as a prefix to the client's conversation. This attack is invisible to the client and looks like an ordinary renegotiation to the server. The extension defined in this document allows renegotiation to be performed safely. Servers SHOULD NOT allow clients to renegotiate without using this extension. Many servers can mitigate this attack simply by refusing to renegotiate at all.
このドキュメントで説明されている拡張機能は、TLSへの攻撃を防ぎます。この拡張機能が使用されていない場合、TLSの再交渉は、攻撃者がクライアントの会話のプレフィックスとしてTLSサーバーとの独自の会話を注入できる攻撃の対象となります。この攻撃はクライアントには見えず、サーバーへの通常の再交渉のように見えます。このドキュメントで定義されている拡張機能により、再交渉を安全に実行できます。サーバーは、この拡張機能を使用せずにクライアントが再交渉できるようにしてはなりません。多くのサーバーは、単に再交渉を拒否するだけでこの攻撃を軽減できます。
While this extension mitigates the man-in-the-middle attack described in the overview, it does not resolve all possible problems an application may face if it is unaware of renegotiation. For example, during renegotiation, either the client or the server can present a different certificate than was used earlier. This may come as a surprise to application developers (who might have expected, for example, that a "getPeerCertificates()" API call returns the same value if called twice), and might be handled in an insecure way.
この拡張機能は、概要で説明されている中間の攻撃を軽減しますが、再交渉に気付いていない場合、アプリケーションが直面する可能性のあるすべての問題を解決しません。たとえば、再交渉中、クライアントまたはサーバーのいずれかが以前に使用されたものとは異なる証明書を提示できます。これは、アプリケーション開発者（たとえば、「getPeercertificates（）」APIコールが2回呼び出された場合と同じ値を返すことを期待していたかもしれない驚きとしてもたらされ、不安定な方法で処理される可能性があります。
TLS implementations SHOULD provide a mechanism to disable and enable renegotiation.
TLSの実装は、再交渉を無効にして有効にするメカニズムを提供する必要があります。
TLS implementers are encouraged to clearly document how renegotiation interacts with the APIs offered to applications (for example, which API calls might return different values on different calls, or which callbacks might get called multiple times).
TLS実装者は、再交渉がアプリケーションに提供されるAPIとどのように相互作用するかを明確に文書化することをお勧めします（たとえば、API呼び出しは異なる呼び出しで異なる値を返す可能性があります。
To make life simpler for applications that use renegotiation but do not expect the certificate to change once it has been authenticated, TLS implementations may also wish to offer the applications the option to abort the renegotiation if the peer tries to authenticate with a different certificate and/or different server name (in the server_name extension) than was used earlier. TLS implementations may alternatively offer the option to disable renegotiation once the client certificate has been authenticated. However, enabling these options by default for all applications could break existing applications that depend on using renegotiation to change from one certificate to another. (For example, long-lived TLS connections could change to a renewed certificate; or renegotiation could select a different cipher suite that requires using a different certificate.) Finally, designers of applications that depend on renegotiation are reminded that many TLS APIs represent application data as a simple octet stream; applications may not be able to determine exactly which application data octets were received before, during, or after renegotiation. Especially if the peer presents a different certificate during renegotiation, care is needed when specifying how the application should handle the data.
再交渉を使用するが、証明書が認証されたら変更が変更されることを期待しないアプリケーションのライフをより簡単にするために、TLS実装は、ピアが別の証明書および/で認証しようとする場合、再交渉を中止するオプションをアプリケーションに提供することもできます。または、以前に使用されたものとは異なるサーバー名（server_name拡張機能）。TLSの実装は、クライアント証明書が認証された後、再交渉を無効にするオプションを提供する場合があります。ただし、すべてのアプリケーションでデフォルトでこれらのオプションを有効にすると、再交渉を使用してある証明書から別の証明書に変更することに依存する既存のアプリケーションを破る可能性があります。（たとえば、長寿命のTLS接続は更新された証明書に変更される可能性があります。または再交渉は、別の証明書を使用する必要がある別の暗号スイートを選択できます。）最後に、再交渉に依存するアプリケーションの設計者は、多くのTLS APIがアプリケーションデータを表すことを思い出しますシンプルなオクテットストリームとして。アプリケーションは、再交渉の前、最中、または再交渉後に受信されたアプリケーションデータを正確に判断できない場合があります。特に、ピアが再交渉中に異なる証明書を提示する場合、アプリケーションがデータを処理する方法を指定する際には注意が必要です。
IANA has added the extension code point 65281 (0xff01), which has been used for prototype implementations, for the "renegotiation_info" extension to the TLS ExtensionType values registry.
IANAは、プロトタイプ実装に使用されている拡張コードポイント65281（0xff01）を追加しました。
IANA has added TLS cipher suite number 0x00,0xFF with name TLS_EMPTY_RENEGOTIATION_INFO_SCSV to the TLS Cipher Suite registry.
IANAは、TLS_EMPTY_RENEGOTIATION_INFO_SCSVを備えたTLS Cipher Suite番号0x00,0xffをTLS Cipher Suiteレジストリに追加しました。
This vulnerability was originally discovered by Marsh Ray and independently rediscovered by Martin Rex. The general concept behind the extension described here was independently invented by Steve Dispensa, Nasko Oskov, and Eric Rescorla with refinements from Nelson Bolyard, Pasi Eronen, Michael D'Errico, Stephen Farrell, Michael Gray, David-Sarah Hopwood, Ben Laurie, David Makepeace, Bodo Moeller, Martin Rex, Peter Robinson, Jesse Walker, Nico Williams, and other members of the Project Mogul team and the TLS WG.
この脆弱性はもともとマーシュレイによって発見され、マーティンレックスによって独立して再発見されました。ここで説明する拡張の背後にある一般的な概念は、スティーブ・ディスペンサ、ナスコ・オスコフ、エリック・レスコルラによって独立して発明されました。Makepeace、Bodo Moeller、Martin Rex、Peter Robinson、Jesse Walker、Nico Williams、およびProject Mogulチームの他のメンバーとTLS WG。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security」、RFC 4347、2006年4月。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
[RFC5056]ウィリアムズ、N。、「チャンネルを保護するためのチャネルバインディングの使用について」、RFC 5056、2007年11月。
[TLS-CHANNEL-BINDINGS] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", Work in Progress, October 2009.
[TLS-Channel-bindings] Altman、J.、Williams、N。、およびL. Zhu、「TLSのチャネルバインディング」、2009年10月の作業。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、E。、「TLS上のHTTP」、RFC 2818、2000年5月。
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2965, October 2000.
[RFC2965] Kristol、D。およびL. Montulli、「HTTP状態管理メカニズム」、RFC 2965、2000年10月。
[Ray09] Ray, M., "Authentication Gap in TLS Renegotiation", November 2009, <http://extendedsubset.com/?p=8>.
[Ray09] Ray、M。、「TLS RENEGOTIATIONの認証ギャップ」、2009年11月、<http://extendedsubset.com/?p=8>。
[SSLv3] Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol Version 3.0", Work in Progress, November 1996.
[SSLV3] Freier、A.、Karlton、P。、およびP. Kocher、「SSLプロトコルバージョン3.0」、1996年11月、Work in Progress。
Authors' Addresses
著者のアドレス
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 USA
Eric Rescorla RTFM、Inc。2064 Edgewood Drive Palo Alto、CA 94303 USA
EMail: ekr@rtfm.com
Marsh Ray PhoneFactor 7301 W 129th Street Overland Park, KS 66213 USA
Marsh Ray PhoneFactor 7301 W 129th Street Overland Park、KS 66213 USA
EMail: marsh@extendedsubset.com
Steve Dispensa PhoneFactor 7301 W 129th Street Overland Park, KS 66213 USA
Steve Dispensa PhoneFactor 7301 W 129th Street Overland Park、KS 66213 USA
EMail: dispensa@phonefactor.com
Nasko Oskov Microsoft One Microsoft Way Redmond, WA 98052 USA
Nasko Oskov Microsoft One Microsoft Way Redmond、WA 98052 USA
EMail: nasko.oskov@microsoft.com