Internet Engineering Task Force (IETF)
Request for Comments: 5746
Updates: 5246, 4366, 4347, 4346, 2246
分類: スタンダードトラック
ISSN: 2070-1721
E. Rescorla
RTFM, Inc.
M. Ray
S. Dispensa
PhoneFactor
N. Oskov
Microsoft.
2010年 2月

(作業中)

English

TLS 再交渉表示拡張
(Transport Layer Security (TLS) Renegotiation Indication Extension)

要旨

(作業中)

SSL(Secure Socket Layer)とTLS(Transport Layer Security)再交渉(renegotiation)は、ある攻撃に対して脆弱である。その攻撃においては、攻撃者は、標的とするサーバとの TLS コネクション を形成し、
of his choice
content を注入し、
そして、クライアントからの新しい TLS コネクション 中につなぎ合わせる。そのサーバは、クライアントの初期 TLS ハンドシェイクを 再交渉として扱い、それゆえ、
「攻撃者によって転送された初期データは、
the subsequent クライアントデータと同一主体からのものである」と信じる。この仕様は、暗号技術的に再交渉を
they are being performed over
the TLS コネクションs に結びつける TLS 拡張を定義するので、この攻撃を防ぐ。

このメモの位置づけ

これは、Internet Standards Track document である。

本書は、IETF(Internet Engineering Task Force)の成果物である。これは、IETF コミュニティのコンセンサスを表現している。これは、パブリックレビューを受け、IESG(Internet Engineering Steering Group)によって発行を承認されたものである。Internet Standards についての詳細は、RFC 5741の 2 章から得られる。

本書の現在の位置づけ(status)についての情報、あらゆる誤記(errata)および「どのように、これについてフィードバックを提供するか?」は、「http://www.rfc-editor.org/info/rfc6066」から入手できる。


著作権表記

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

本書は、本書の発行日において有効な IETF Documents (http://trustee.ietf.org/license-info) に関する BCP 78 および IETF Trust の法的規制の対象となる。これらの文書を注意深く読み返していただきたい。なぜならば、それらは、本書に関するあなたの権利と制約を記述しているからである。本書から抽出されたコード Components は、Trust Legal Provisions の 4.e 節に記述されているように Simplified BSD License text を含まなければならないし、Simplified BSD License に記述されているように保証なしで提供されなければならない。

 

目次

1. はじめに
2. 本書において使われている慣行
3. セキュアな再交渉の定義

3.1. Additional Connection State
3.2. 拡張 Definition
3.3. 再交渉 Protection Request Signaling Cipher Suite Value
3.4. クライアントの振る舞い: 初期ハンドシェイク
3.5. クライアントの振る舞い: セキュアな再交渉
3.6. サーバの振る舞い: 初期ハンドシェイク
3.7. サーバの振る舞い: セキュアな再交渉

4. 下位互換性

4.1. クライアントの考慮事項
4.2. クライアントの振る舞い: Legacy (Insecure) 再交渉
4.3. サーバ Considerations
4.4. サーバの振る舞い: Legacy (Insecure) 再交渉
4.5. SSLv3

5. セキュリティについての考慮事項
6. IANA に関する考慮事項
7. 謝辞
8. 参考文献

8.1. 規範的参考文献
8.2. 参考資料


1.  はじめに
English

(作業中)

TLS [RFC5246] は、クライアントかあるいはサーバのいずれかが、再交渉(新しい暗号技術的パラメータを確立する新しいハンドシェイク)を開始できるようにする。残念ながら、新しいハンドシェイクは、当初のハンドシェイクによって確立された暗号技術的パラメータを使って行われるが、両者の間に暗号技術的 binding は無い。これは、
in which the 攻撃者 who can intercept a クライアントの transport layer connection can inject traffic of his own as a prefix to the クライアントの interaction with the サーバ
an 攻撃の機会を創り出す。 この攻撃 [Ray09] の一形態は、下記のように進行する。:

   Client                        Attacker                        Server
   ------                        -------                         ------
                                     <----------- Handshake ---------->
                                     <======= Initial Traffic ========>
   <--------------------------  Handshake ============================>
   <======================== Client Traffic ==========================>

この攻撃を開始するために、攻撃者は、
forms a TLS コネクション to the サーバ
(perhaps in response to an initial intercepted connection from the クライアント)。
彼は、次に、
any traffic of his choice to the サーバ
を送る。これは、
may involve multiple requests and responses at the application layer,
or may simply be a partial application layer request intended to prefix the クライアントのデータ。
この traffic は、
it is encrypted
を示すために、「==」と共に示されている。彼は、次に、
allows the クライアントの TLS ハンドシェイク to proceed with the サーバ。
そのハンドシェイクは、
is in the clear to the 攻撃者
but encrypted over the 攻撃者の TLS コネクション to the サーバ。
ひとたび、そのハンドシェイクが完了すると、そのクライアントは、
over the newly established セキュリティ パラメータs with the サーバ
the サーバと通信する。攻撃者は、この traffic を読めないが、そのサーバは、
「the initial traffic to and from the 攻撃者
は、
is the same as that to and from the クライアント」
と信じる。

証明書-based クライアント認証(authentication)が使われている場合、そのサーバは、
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 クライアントの証明書。
In some プロトコルs (notably HTTPS),
no distinction is made between pre- and post-authentication stages and the bytes are handled uniformly,
resulting in the サーバ believing that the initial traffic corresponds to the authenticated クライアント identity。
Even without 証明書-based 認証,
多様な攻撃
in which the 攻撃者 convinces the サーバ to accept データ from it as データ from the クライアント
が可能である可能性がある。例えば、HTTPS [RFC2818] が HTTP cookies [RFC2965] と共に使われている場合、その攻撃者は、
a request を
of his choice validated by the クライアントの cookie
生成できる可能性がある。

(IMAP もしくは SMTP のような)プロトコルには、
more explicit transitions between authenticated and unauthenticated phases
をもち、
require that 「the プロトコル state machine be partly or fully reset at such transitions」
ものがある。厳密に従った場合、これらのルールは、攻撃の影響を制限する可能性がある。残念ながら、
there is no requirement for state machine resets at TLS 再交渉。
そして、それゆえ、
there is still a potential window of 脆弱性,
例えば、
by prefixing a command that writes to an area visible by the 攻撃者 with a command by the クライアント that includes his password,
thus making the クライアントの password visible to the 攻撃者
(「この precise 攻撃は、challenge-response authentication schemes では作用しないが、他の攻撃は、
be possible
可能性があること」に注意)。
同様の攻撃は、
are available with SMTP,
and in fact do not necessarily require the 攻撃者 to have an account on the target サーバ。

「in both cases、
これらの攻撃は、
the クライアントが
sends unsolicited 認証(authentication)情報 without requiring any specific データ from the サーバ over the TLS connection
ので、可能であること 」
を注意することは、重要である。
a round trip to the サーバ over TLS before the クライアント sends sensitive 情報
を要求するプロトコルは、相対的に脆弱でない傾向がある。

これらの攻撃は、暗号技術的に再交渉ハンドシェイクを
the enclosing TLS 暗号技術的パラメータs
に結合することによって、予防される可能性がある。それゆえ、
allowing the サーバ to differentiate 再交渉 from 初期交渉, as well as preventing 再交渉s from being spliced in between connections。
An attempt by an 攻撃者 to inject himself as described above
は、
a mismatch of the 暗号技術的 binding and can thus be detected
をもたらす。この拡張中に使われているデータは、
is similar to, but not the same as,
the データ used in the tls-unique and/or tls-unique-for-telnet channel bindings described in [TLS-CHANNEL-BINDINGS]。;
しかし、この拡張は、
a general-purpose RFC 5056 [RFC5056] channel binding facility
ではない。

 

2. 本書において使われている慣行 English

本書中の MUSTMUST NOTREQUIREDSHALLSHALL NOTSHOULDSHOULD NOTRECOMMENDEDMAYOPTIONAL は、 [RFC2119] に記述されたように解釈されるべきものである。

 

3. セキュアな再交渉の定義 English

 

3.1. Additional Connection State English

(作業中)

クライアントとサーバの両方は、
to store 3 additional values for each TLS コネクション state (RFC 5246, 6.1 節を参照)
必要がある。「こららの値は、
(not a TLS session cache entry)
connection に固有であること」に注意。

3.2. 拡張 定義 English

(作業中)

本書は、
新しい TLS 拡張, "renegotiation_info" (with 拡張 type 0xff01), which contains a 暗号技術的 binding to the enclosing TLS コネクション (if any) for which the 再交渉 is being performed
を定義する。この拡張の "extension data" field は、"RenegotiationInfo" structure を格納する。:

      struct {
          opaque renegotiated_connection<0..255>;
      } RenegotiationInfo;

この拡張の contents は、下記のように
are specified。

この拡張は、Datagram TLS (DTLS) [RFC4347] と共に使われる可能性もある。
Although,
for editorial simplicity,
本書は、
refers to TLS,
all requirements in 本書 apply equally to DTLS。

3.3. 再交渉 Protection Request Signaling Cipher Suite 値 English

(作業中)

SSLv3 と TLS 1.0/TLS 1.1 の両方の仕様は、実装に
following the ClientHello (i.e., 拡張s) if they do not understand it
データを無視することを要求する。しかし、SSLv3 と TLS 1.0 の実装には、
incorrectly fail the ハンドシェイク in such a case
ものがある。これは、
「that offer the "renegotiation_info" 拡張
クライアントは、ハンドシェイク失敗に直面する可能性があること」を意味する。
In order to enhance compatibility with このようなサーバs,
本書は、
a 2nd signaling メカニズム via a special SCVP(Signaling Cipher Suite Value)"TLS_EMPTY_RENEGOTIATION_INFO_SCSV", with code point {0x00, 0xFF}
を定義する。この SCSV は、
a true cipher suite ではなく(it does not correspond to any valid set of algorithms)、
cannot be negotiated。
代わりに、これは、(以降の節に記述されているように)空の "renegotiation_info" 拡張と同一の semantics をもつ。SSLv3 と TLS の実装は、
reliably ignore unknown cipher suites
ので、SCSV は、あらゆるサーバ宛に安全に送られる可能性がある。SCSV は、
SSLv2 backward compatible CLIENT-HELLO(Appendix E.2 of [RFC5246] 参照)
中に含められることもできる。

Note:
再交渉をまったくサポートしていない minimal クライアントは、
simply use the SCSV in all initial ハンドシェイクs
できる。下記の節において、その ルールは、
will cause any compliant サーバ to abort the ハンドシェイク when it sees an apparent attempt at 再交渉 by such a クライアント。

3.4. クライアントの振る舞い: 初期ハンドシェイク English

(作業中)

「本節および 3.5 節は、
apply to both full ハンドシェイクs and session resumption ハンドシェイクs」
に注意。

3.5. クライアントの振る舞い: セキュアな再交渉 English

(作業中)

この text は、
applies
if the connection's "secure_renegotiation" フラグ is set to TRUE
( it is set to FALSE
場合、
4.2節を参照)。

3.6. サーバの振る舞い: 初期ハンドシェイク English

(作業中)

「本節と 3.7節は、
apply to
full ハンドシェイクと session-resumption ハンドシェイクの両方」
に注意。

この仕様を実装する TLS サーバは、
offered by the クライアント
あらゆるy unknown 拡張を無視しなければならない(MUST)。そして、それらは、
accept version numbers higher than their highest version number and negotiate the highest common version
ならない(MUST)。これらふたつの要件は、
reiterate preexisting requirements in RFC 5246 and are merely stated here in the interest of forward compatibility。

Note that
「 a "renegotiation_info" 拡張 in response to a ClientHello containing only the SCSV
を送信することは、
an explicit exception to the prohibition in RFC 5246, 7.4.1.4節, on the サーバ sending unsolicited 拡張s
であり、
is only allowed because the クライアント is signaling its willingness to receive the 拡張 via the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV」。
TLS 実装は、
7.4.1.4節 for all 他の拡張s
に準拠し続けなければならない(MUST)

3.7. サーバの振る舞い: セキュアな再交渉 English

(作業中)

この text は、その connection の "secure_renegotiation" フラグに TRUE がセットされている場合、
applies。
(it is set to FALSE
場合、4.4節を参照。)

4. 下位互換性 English

(作業中)

この拡張をサポートしていない既存の実装は、
are widely deployed and,
in general, must interoperate with newer 実装s that do support it。
本章は、下位互換な interoperation についての考慮事項を記述する。

4.1. クライアントの考慮事項 English

(作業中)

あるクライアントが
offers the "renegotiation_info" 拡張 or the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV and the サーバ does not reply with "renegotiation_info" in the ServerHello
場合、これは、「そのサーバは、セキュアな再交渉をサポートしていないこと」を示す。
some 攻撃s (1章を参照)look like a single ハンドシェイク to the クライアント
ので、そのクライアントは、「その connection は、現在、攻撃にさらされているか否か?」を判定できない。しかし、
「merely because the サーバ does not acknowledge the 拡張 does not mean that it is vulnerable ;
it might choose to reject all 再交渉s and simply not signal it」
に注意。しかし、そのクライアントにとって、純粋 TLS メカニズム経由で
「whether or not this is the case?」を判定することは、不可能である。

クライアントが「このような攻撃が不可能であること」を確認することを望む場合、それらは、
to terminate the connection immediately upon failure to receive the 拡張 without completing the ハンドシェイク
必要がある。このようなクライアントは、
a fatal "handshake_failure" alert prior to terminating the connection
を生成しなければならない(MUST)。しかし、
it is expected that many TLS サーバs that do not support 再交渉 (and thus are not vulnerable) will not support この拡張 either,
so in general,
that implement this behavior
クライアントは、相互運用可能性問題に直面する。
There is no set of クライアントの振る舞いs that will guarantee セキュリティ and achieve maximum interoperability during the transition period。
クライアントは、
to choose one or the other preference when dealing with potentially un-upgraded サーバs
必要がある。

4.2. クライアントの振る舞い: Legacy (Insecure) 再交渉 English

(作業中)

この text は、
applies if the connection's "secure_renegotiation" フラグ is set to FALSE。

It is possible that un-upgraded サーバs will request that the クライアント renegotiate。
It is RECOMMENDED that
「 クライアントs refuse this 再交渉 request」。
クライアントs 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 サーバ is in fact an 攻撃者 who is then allowing the クライアント to renegotiate with a different, legitimate, upgraded サーバ。
クライアントが
nevertheless choose to renegotiate
場合、they は、
behave as described below
ならない(MUST)

that choose to renegotiate
クライアントは、
either the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV
or "renegotiation_info" in their ClientHello
提供しなければならない(MUST)
In a legitimate 再交渉 with an un-upgraded サーバ,
that サーバ should ignore both of these signals。
しかし、
the サーバ (incorrectly) fails to ignore 拡張s
場合、
sending the"renegotiation_info" 拡張 may cause a ハンドシェイク failure。
それゆえ、
it is permitted,
though NOT RECOMMENDED,
for the クライアント to simply send the SCSV。
これは、
is the only situation in which クライアントs are permitted to not send the "renegotiation_info" 拡張 in a ClientHello that is used for 再交渉。

Note that
「in the case of a downgrade 攻撃,
if this is an initial ハンドシェイク from the サーバ's perspective,
then use of the SCSV from the クライアント precludes detection of this 攻撃 by the サーバ
(if this is a 再交渉 from the サーバ's perspective, then it will detect the 攻撃)」。
しかし、その攻撃は、
will be detected by the クライアント when the サーバ sends an empty "renegotiation_info" 拡張 and the クライアント is expecting one containing the previous verify_data。 |
By contrast,
the クライアント sends the "renegotiation_info" 拡張
場合、そのサーバは、
will immediately detect the 攻撃。

ServerHello が
is received
とき、そのクライアントは、
verify that
「it does not contain the "renegotiation_info" 拡張」
ならない(MUST)
it does
場合、そのクライアントは、
abort the ハンドシェイク
ならない(MUST)
(Because the サーバ has already indicated it does not support セキュアな再交渉,
the only way that this can happen is if the サーバ is broken or there is an 攻撃。)

4.3. サーバ 考慮事項 English

(作業中)

the クライアントが
does not offer the "renegotiation_info" 拡張 or the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV
場合、これは、
「the クライアント does not support セキュアな再交渉」
を示す。
Although the 攻撃 described in Section 1 looks like two ハンドシェイクs to the サーバ,
他の攻撃s may be possible in which the 再交渉 is seen only by the クライアント。
サーバs が
wish to ensure that such 攻撃s are impossible
場合、
they need to terminate the connection immediately upon failure to negotiate the use of セキュアな再交渉。
Servers that do choose to allow connections from unpatched クライアントs
は、
can still prevent the 攻撃 described in Section 1 by refusing to renegotiate over those connections。

In order to enable クライアントs to probe,
even サーバs that do not support 再交渉
は、
implement the minimal version of the 拡張 described in 本書 for initial ハンドシェイクs, thus signaling that they have been upgraded
ならない(MUST)

4.4. サーバの振る舞い: Legacy (Insecure) 再交渉 English

(作業中)

この text は、
applies
if the connection's "secure_renegotiation" フラグ is set to FALSE。

It is RECOMMENDED that
「サーバs not permit legacy 再交渉」。
サーバs nevertheless do permit it
場合、they は、
follow the requirements in this section
ならない(MUST)

4.5. SSLv3 English

(作業中)

While SSLv3 is not a プロトコル under IETF change control ( [SSLv3]参照),
it was the original basis for TLS and most TLS 実装s also support SSLv3。
The IETF は、
encourages SSLv3 実装s to adopt the "renegotiation_info" 拡張 and SCSV as defined in 本書。
The semantics of the SCSV and 拡張
は、
are identical to TLS stacks except for the size of the verify_data values,
which are 36 bytes long each。
「これは、
adding at least minimal 拡張 processing to such stacks
を要求すること」に注意。
SSLv3 をサポートし、
offer セキュアな再交渉 (either via SCSV or"renegotiation_info")
クライアントは、
the "renegotiation_info" 拡張 from the サーバ, even if the サーバ version is {0x03, 0x00}, and behave as described in この仕様
許容しなければならない(MUST)
that support セキュアな再交渉 and support SSLv3
TLS サーバは、
SCSV or the"renegotiation_info" 拡張 and respond as described in this specification even if the offered クライアント version is {0x03, 0x00}
許容しなければならない(MUST)。SSLv3 は、"no_renegotiation" alert を定義していない。
(そして、
does not offer a way to indicate a refusal to renegotiate at a "warning" level。)
再交渉を拒絶する SSLv3 クライアントは、fatal handshake_failure alert を使う必要がある(SHOULD)

 

5. セキュリティについての考慮事項 English

(作業中)

本書中に記述された拡張は、TLS についての、ある攻撃を予防する。この拡張が使われない場合、TLS 再交渉は、
an 攻撃 in which the 攻撃者 can inject their own conversation with the TLS サーバ as a prefix to the クライアントの conversation
の対象となる。この攻撃は、
is invisible to the クライアント and looks like an ordinary 再交渉 to the サーバ。
The 拡張 defined in 本書
は、
allows 再交渉 to be performed safely。
Servers は、
allow クライアントs to renegotiate without using この拡張
いけない(SHOULD NOT)。多くのサーバは、
mitigate この攻撃 simply by refusing to renegotiate at all
できる。

While この拡張 mitigates the man-in-the-middle 攻撃 described in the overview,
これらは、
all possible 問題 an application may face if it is unaware of 再交渉
解決しない。例えば、再交渉において、
either the クライアント
or the サーバ can present a 異なる証明書 than was used earlier。
これは、
may come as a surprise to application developers
(who might have expected,
例えば、
that a "getPeerCertificates()" API call returns the same value if called twice),
and might be handled in an insecure way。

TLS 実装は、再交渉を不能にしたり可能にしたりするための メカニズム を提供する必要がある(SHOULD)

TLS 実装者は、
are encouraged to clearly document how 再交渉 interacts with the APIs offered to アプリケーション
(例えば、
which API calls might return different values on different calls, or which callbacks might get called multiple times)。

To make life simpler for アプリケーション that use 再交渉 but do not expect the 証明書 to change once it has been authenticated,
TLS 実装は、
may also wish to offer the アプリケーション the option to abort the 再交渉 if the peer tries to authenticate with a different 証明書 and/or different サーバ名
(in the server_name 拡張) than was used earlier。
TLS 実装は、
alternatively offer the option to disable 再交渉 once the クライアント 証明書 has been authenticated
可能性がある。しかし、
enabling これらの options by default for all アプリケーション could break 既存のアプリケーション that depend on using 再交渉 to change from one 証明書 to another。
(例えば、long-lived TLS コネクションは、
could change to a renewed 証明書。;
or 再交渉 could select a different cipher suite that requires using a different 証明書。)

最後に、再交渉に依拠するアプリケーションの設計者には、
「多くの TLS API が
represent application データ as a simple octet stream」
が推奨される。アプリケーションは、
not be able to determine exactly which application データ octets were received before, during, or after 再交渉
可能性がある。特に、
the peer presents a 異なる証明書 during 再交渉
場合、
「どのように
the application should handle the データ?」
を規定するとき、配慮を要する。

 

6. IANA に関する考慮事項 English

(作業中)

IANA は、拡張 code point 65281(0xff01)を追加した。これは、
has been used for prototype 実装s,
for the "renegotiation_info" 拡張 to the TLS ExtensionType values registry。

IANA は、TLS cipher suite number 0x00,0xFF を name TLS_EMPTY_RENEGOTIATION_INFO_SCSV と共に TLS Cipher Suite registry に追加した。

 
7. 謝辞 English

(作業中)

この脆弱性は、当初、Marsh Ray によって発見され、独立して Martin Rex によって再発見された。
described here
the 拡張の背後にある一般概念は、
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。

8. 参考文献

8.1. 規範的参考文献

[RFC2119] Bradner, S.,
"Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, 1997年 3月.
[RFC5246] Dierks, T. and E. Rescorla,
"The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, 2008年 8月.

 

8.2. 参考資料
[RFC4347] Rescorla, E. and N. Modadugu,
"Datagram Transport Layer Security", RFC 4347, 2006年 4月.
[RFC5056] Williams, N.,
"On the Use of Channel Bindings to Secure Channels", RFC 5056, 2007年11月.
[TLS-CHANNEL-BINDINGS] Altman, J., Williams, N., and L. Zhu,
"Channel Bindings for TLS", Work in Progress, 2009年10月.
[RFC2818] Rescorla, E.,
"HTTP Over TLS", RFC 2818, 2000年 5月.
[RFC2965] Kristol, D. and L. Montulli,
"HTTP State Management Mechanism", RFC 2965, 2000年10月.
[Ray09] Ray, M.,
"Authentication Gap in 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, 1996年11月.

 

著者のアドレス

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

EMail: marsh@extendedsubset.com

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

EMail: nasko.oskov@microsoft.com