Internet Engineering Task Force (IETF)
Request for Comments: 6066
廃止: 4366
分類: スタンダードトラック
ISSN: 2070-1721

D. Eastlake 3rd
Huawei
2011年 1月

English

TLS 拡張: 拡張定義
(Transport Layer Security (TLS) Extensions: Extension Definitions)

要旨

本書は、既存の TLS 拡張についての仕様を提供する。これは、RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2"の副読本である。規定されている拡張は、server_name、max_fragment_length、client_certificate_url、trusted_ca_keys、truncated_hmac および status_request である。

このメモの位置づけ

これは Internet Standards Track 文書である。

本書は、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) 2011 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 に記述されているように保証なしで提供されなければならない。

本書は、2008年11月10日以前に発行もしくは公開された IETF 文書もしくは IETF Contributions からの素材を含む可能性がある。この素材のいくつかにおける著作権を統制する人(々)は、IETF Trust に対して、このような素材の IETF 標準化過程以外における改変を許容する権利を許可していない可能性がある。このような素材における著作権を統制している人(々)から適切なライセンスを得ること無しに、本書は、IETF 標準化過程以外において改変されてはいけない。そして、その derivative works は、RFC としての発行のためにフォーマットを整えること、あるいは、これを英語以外の言語に翻訳することを除いて、IETF 標準化過程以外で行われてはいけない。

目次

1. はじめに
1.1. 対象とする具体的な拡張
1.2. 本書における用語法
2. ハンドシェイクプロトコルに対する拡張
3. サーバ名表示
4. 最大フラグメント長の交渉
5. クライアント証明書 URL
6. Trusted CA 表示
7. 切り詰められた HMAC
8. 証明書状態リクエスト
9. エラー警告
10. IANA についての考慮事項
10.1. pkipath MIME 種別の登録
10.2. TLS 警告、TLS HandshakeTypes および’ ExtensionTypes への参照
11. セキュリティについての考慮事項
11.1. server_name についてのセキュリティの考慮事項
11.2. max_fragment_length についてのセキュリティの考慮事項
11.3. client_certificate_url についてのセキュリティの考慮事項
11.4. trusted_ca_keys についてのセキュリティの考慮事項
11.5. truncated_hmac についてのセキュリティの考慮事項
11.6. status_request についてのセキュリティの考慮事項
12. 規範的参考文献
13. 参考情報
Appendix A. RFC 4366 からの変更点
Appendix B. 謝辞

1. はじめに English

TLS(Transport Layer Security)プロトコル Version 1.2 は、[RFC5246] に規定されている。その仕様は、TLS の拡張についてのフレームワーク、このような拡張を設計する際の考慮事項([RFC5246] の 7.4.1.4節を参照)、および、新しい拡張 code point の割り当て(allocation)についての IANA 考慮事項 を含む。しかし、これは、署名 Algorithms 以外のいかなる特定の拡張も規定しない([RFC5246] の 7.4.1.4.1節を参照)。本書は、既存の TLS 拡張についての仕様を提供する。これ(本書)は、(その大部分は)RFC 4366 からの素材を採用して編集したものである。これ(RFC 4366)は、TLS 1.0(RFC 2246)と TLS 1.1(RFC 4346)についての TLS 拡張を扱っていた。

1.1. 対象とする具体的な拡張 English
ここに記述されている拡張は、TLS プロトコルメッセージフォーマットによって提供されている機能を拡張することに焦点を当てる。新しいcipher suite の追加のような他の論点は、見送られた。

本書中に定義された拡張種別は、下記のとおり。:

      enum {
          server_name(0), max_fragment_length(1),
          client_certificate_url(2), trusted_ca_keys(3),
          truncated_hmac(4), status_request(5), (65535)
      } ExtensionType;

具体的には、本書中に記述されている拡張は、:

TLS のクライアント とサーバは、本書中に記述された拡張を使う可能性がある。この拡張は、下位互換となるように設計された。これは、「拡張をサポートする TLS クライアントは、その拡張をサポートしない TLS サーバと話すことができること、および、その逆もできること(vice versa)」を意味する。

「TLS ハンドシェイクにおいて送信されるこれらの拡張に関するあらゆるメッセージは、"Finished" メッセージに含まれている hash 計算中に含まれなければならない(MUST)こと」に注意。

「本書中に定義されているすべての拡張は、あるセッションが開始されるときのみ、関連すること」にも注意。セッション再開(resumption)を要求するクライアントは、一般に、「そのサーバがこの request を受容するか否か?」を知らない。それゆえ、それは、中断を試みるのでないならば送った拡張と同一のものを送る必要がある(SHOULD)。クライアントがセッション再開をリクエストする過程で、拡張されたクライアント hello 中に定義された拡張種別のひとつ、もしくは複数を含むとき :

1.2. 本書における用語法 English

本書中の MUS,、MUST NOTREQUIREDSHALLSHALL NOTSHOULDSHOULD NOTRECOMMENDEDMAYOPTIONAL は、BCP 14, RFC 2119 [RFC2119] に記述されたように解釈されるべきものである。

2. ハンドシェイクプロトコルに対する拡張 English

本書は、ふたつの新しい ハンドシェイクメッセージ("CertificateURL" および "CertificateStatus")の利用を規定する。これらのメッセージは、この順に 5章と 8章に記述されている。それゆえ、新しい ハンドシェイク メッセージ構造体は、下記のようになる。:

   enum {
       hello_request(0), client_hello(1), server_hello(2),
       certificate(11), server_key_exchange (12),
       certificate_request(13), server_hello_done(14),
       certificate_verify(15), client_key_exchange(16),
       finished(20), certificate_url(21), certificate_status(22),
       (255)
   } HandshakeType;
   struct {
       HandshakeType msg_type;    /* handshake type */
       uint24 length;             /* bytes in メッセージ */
       select (HandshakeType) {
           case hello_request:       HelloRequest;
           case client_hello:        ClientHello;
           case server_hello:        ServerHello;
           case certificate:         Certificate;
           case server_key_exchange: ServerKeyExchange;
           case certificate_request: CertificateRequest;
           case server_hello_done:   ServerHelloDone;
           case certificate_verify:  CertificateVerify;
           case client_key_exchange: ClientKeyExchange;
           case finished:            Finished;
           case certificate_url:     CertificateURL;
           case certificate_status:  CertificateStatus;
       } body;
   } Handshake;


    
3. サーバ名表示 English

TLS は、クライアント用に、サーバ宛にクライアントがコンタクトしようとしているサーバの名前を伝えるためのメカニズムを提供しない。これは、クライアント用に単一の基盤となっている(underlying)ネットワークアドレスで複数の「バーチャル」サーバをホストするサーバへのセキュアな接続を容易にするために、この情報を提供するために渇望される可能性がある。

サーバ名を提供するために、クライアントは、(拡張された) クライアント hello 中に 種別が "server_name" の拡張を含む可能性がある(MAY)。この拡張の"extension_data" フィールドは、"ServerNameList" を納めるものとする(SHALL)。これは、下記のとおり。:

      struct {
          NameType name_type;
          select (name_type) {
              case host_name: HostName;
          } name;
      } ServerName;
      enum {
          host_name(0), (255)
      } NameType;
      opaque HostName<1..2^16-1>;
      struct {
          ServerName server_name_list<1..2^16-1>
      } ServerNameList;
ServerNameList は、複数の same   
  name_type を収めてはならない(MUST NOT)。サーバが ClientHello 拡張は解釈できるが、サーバ名を解釈できない場合、そのサーバは、(次の)ふたつにひとつのアクションをとる必要がある(SHOULD)。
    : fatal   
  レベルの unrecognized_name(112) alert を送ることによって、そのハンドシェイクを中断するか、あるいは、そのハンドシェイクを続けるか、のいずれかである。warning レベルの警告に対するクライアントのふるまいは、予測不能であるので、warning-level の unrecognized_name(112) alert を送ることは、推奨されない(NOT   
    RECOMMENDED)。クライアントアプリケーションによって使われるサーバ名と、そのサーバによって選択されたたクレデンシャルのサーバ名の間に不整合がある場合、この不整合は、そのクライアントアプリケーションがサーバ endpoint 識別(identification)を行うとき、そのクライアントアプリケーションが「その通信を続けるか否か?」を判断する必要がある時点で明らかになる。TLS 実装には、アプリケーション開発者に向けて、TLS ハンドシェイクにおいて送受信される
  warning-level 警告についての情報を入手可能にすることが強く薦められる。このような情報は、診断(diagnostic)目的のために有用である可能性がある。

注: この仕様の初期の版は、同一 name_type の複数の名前を許容していた。実際、現在のクライアント実装は、ひとつだけ名前を送り、そのクライアントは、必ずしもそのサーバが選択した名前を見つけ出せるとは限らない。それゆえ、同一 name_type の複数の名前は、今は禁止されている。

現在、サポートされている唯一のサーバ名は、DNS hostname である。しかし、これは、いかなる TLS の DNS への依存性も意味しない。そして、他の名前種別が、将来、(本書を更新する RFC によって)追加される可能性がある。その host_name NameType と関連づけられるそのデータ構造体は、16 bit 長で始まる可変長ベクトルである。後方互換性(backward compatibility)について、新しい NameTypes に関連する将来のすべての data structures は、16 bit 長の field で始まらなければならない(MUAT)。TLS は、提供されたサーバ名を opaque データとして扱い、その名前と種別をアプリケーションに渡す可能性がある(MAY)

"HostName" は、クライアントによって理解されているように、サーバの完全に修飾された DNS ホスト名を納める。ホスト名は、連結するドット無しで ASCII encoding を使って byte string として表現される。これは、[RFC5890] に定義されている A-labels の利用を通じて国際化ドメイン名のサポートを許容する。DNS ホスト名は、大文字/小文字を区別しない(case-insensitive)。ホスト名を比較するためのアルゴリズムは、[RFC5890] の 2.3.2.4節 に記述されている。

Literal な IPv4 アドレスと IPv6 アドレスは、"HostName"において許可されていない。

「クライアントは、あるサーバをサポートされている名前種別によって見つけ出す(locate)ときはいつでも、その client hello 中に種別が "server_name" の拡張を含むこと」が推奨される(RECOMMENDED)

"server_name" 拡張を納めるクライアント hello を受け取るサーバは、クライアント宛に返すための適切な証明書、かつ/または、セキュリティポリシーの他の観点の選択をガイドするために、その拡張中に納められている情報を使う可能性がある(MAY)。この際には、そのサーバは、(拡張された) server hello 中に 種別が "server_name" の拡張を含むものとする(SHALL)。この拡張の "extension_data" フィールドは、空であるものとする(SHALL)

そのサーバが 「あるセッションを再開するためのリクエストを許容するか否か?」を判断するとき、server_name 拡張の内容が、そのセッションキャッシュ内のセッションの lookup において使われる可能性がある(MAY)。そのクライアントは、同一の server_name 拡張を、そのセッション再開リクエスト中に含む必要がある(SHOULD)。なぜならば、それがセッションを確立した full ハンドシェイクにおいて使われたからである。この拡張を実装するサーバは、server_name 拡張が異なる名前を含んでいる場合、そのセッションを再開するために、そのリクエストを受容してはならない(MUST NOT)。代わりに、それは、新しいセッションを確立するために full ハンドシェイクで進める。 あるセッションを再開するとき、そのサーバは、サーバ hello 中に server_name 拡張を含んではならない(MUST NOT)

あるアプリケーションがサーバ名を、あるアプリケーションプロトコルで使うことを交渉し、TLS にアップグレードする場合、かつ server_name 拡張が送られる場合、その拡張は、そのアプリケーションプロトコルにおいて交渉されたのと同一の名前を含む必要がある(SHOULD)。その server_name が TLS セッションハンドシェイクにおいて確立している場合、そのクライアントは、そのアプリケーション層において異なるサーバ名を要求することを試みてはいけない(SHOULD NOT)

4. 最大フラグメント長の交渉 English

この拡張無しに、TLS は、固定最大 plaintext フラグメント長として 2^14 byte と規定する。これは、制約されたクライアント用に、メモリ制約もしくは帯域制限に起因して、より小さな最大フラグメント長を交渉するために渇望される可能性がある。

より小さい最大フラグメント長を交渉するために、クライアントは、(拡張された)クライアント hello 中に種別が "max_fragment_length" の拡張を含む可能性がある(MAY)。この拡張の "extension_data" フィールドは、下記を含むものとする(SHALL)。:

      enum{
          2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
      } MaxFragmentLength;

この値は、渇望される最大フラグメント長である。このフィールドについて、許容される値は、2^9、2^10、2^11 および 2^12 である。

"max_fragment_length" 拡張を含む拡張された クライアント hello を受け取るサーバは、(拡張された) server hello 中に type"max_fragment_length" の拡張を含めることによって要求された最大フラグメント長を受容する可能性がある(MAY)。この拡張の "extension_data" フィールドは、"MaxFragmentLength"を納めるものとする(SHALL)。この値は、要求された最大フラグメント長と同一である。

あるサーバが許容された値以外の値についての最大フラグメント長の交渉 リクエストを受け取る場合、これは、そのハンドシェイクを "illegal_parameter" 警告 で中止しなければならない(MUST)。同様に、あるクライアントがリクエストしたものとは大きさが異なる最大フラグメント長交渉レスポンスを受け取る場合、これも、そのハンドシェイクを "illegal_parameter" 警告で中止しなければならない(MUST)

ひとだび、2^14 以外の最大フラグメント長が成功裡に交渉されたら、そのクライアントおよびサーバは、「交渉された長さより長いフラグメントは、送られないこと」を確保するために、(ハンドシェイクメッセージを含む)メッセージのフラグメント化をただちに始めなければならない(MUST)。「TLS は、クライアントおよびサーバにハンドシェイクメッセージのフラグメンテーションをサポートすることを要求していること」に注意。

交渉された長さは、セッション回復(resumption)を含む、そのセッションの持続(duration)について適用される。

交渉された長さは、そのレコード層がフラグメンテーション無しに処理できる input を制限する。(すなわち、TLSPlaintext.length の最大値。[RFC5246] の 6.2.1節を参照。)「レコード層の output は、より大きい可能性があること」に注意。例えば、交渉された長さが 2^9=512 である場合、現在、定義されているサイファースィート([RFC5246] と [RFC2712]) および null 圧縮、 そのレコード層の output は、高々805 byte (5 byte の header、512 byte の application data、256 byte の padding、32 byte の MAC)となりうるに過ぎない。これは、「TLS レコード層ピアが 805 byte よりも大きい TLS レコード層のメッセージを受け取る際には、そのメッセージを破棄して、"record_overflow" alert を、そのメッセージを復号することなしに送らなければならない(MUST)こと」を意味する。この拡張が DTLS(Datagram Transport Layer Security)と共に使われているとき、実装は、そのパケットがメッセージ認証(authentication)を渡すのでない限り、record_overflow 警告を生成してはいけない(SHOULD NOT)

5. クライアント証明書 URL English

この拡張無しに、TLS は、「クライアント認証が行われるとき、クライアント証明書は、クライアントによってサーバ宛に TLS ハンドシェイクにおいて送られること」を規定している。制約されたクライアント用に、それらの証明書を蓄積する必要がないようにして、メモリを節約できるようにするために、証明書の代わりに証明書 URL を送ることが渇望される可能性がある。

証明書 URL のサーバ宛の送信を交渉するために、クライアントは、(拡張された)クライアント hello 中に種別が "client_certificate_url" の拡張を含む可能性がある(MAY)。この拡張の "extension_data" フィールドは、空であるものとする(SHALL)

(「既存の TLS サーバの "breaking" を避けるために、クライアント証明書 URL の利用を交渉することが必要不可欠であること」に注意。)

"client_certificate_url" 拡張を納める拡張された クライアント hello を受け取るサーバは、「サーバは、(拡張された) サーバ hello 中に種別が "client_certificate_url" の拡張を含めることによって証明書 URL を受容することを望んでいること」を示す可能性がある(MAY)。この拡張の "extension_data" フィールドは、空であるものとする(SHALL)

クライアント証明書 URL の利用の交渉が成功裡に完了した後("client_certificate_url" 拡張を含む hello を交換することによって)、クライアントは、下記のように "Certificate" メッセージの代わりに "CertificateURL" メッセージを送る可能性がある(MAY)。(2章も参照。):

      enum {
          individual_certs(0), pkipath(1), (255)
      } CertChainType;
      struct {
          CertChainType type;
          URLAndHash url_and_hash_list<1..2^16-1>;
      } CertificateURL;
      struct {
          opaque url<1..2^16-1>;
          unint8 padding;
          opaque SHA1Hash[20];
      } URLAndHash;

ここで、"url_and_hash_list" は、一連の URL およびオプションとしてのハッシュを含む。各 "url" は、証明書を取ってくるのに直ちに使え、[RFC3986] に準拠した完全な(absolute)URI reference でなければならない(MUST)

X.509 証明書が使われるとき、ふたつの可能性がある。:

あらゆる他の証明書フォーマットが使われるとき、TLS において、そのフォーマットの利用を記述している仕様は、証明書もしくは証明書チェーンの符号化フォーマット、および、それらの順序について、あらゆる制約を定義する必要がある。

その「パディング(padding)」バイトは、0x01でなければならない(MUST)。これは、その structure を下位互換なものにするために提供される。

各 URL に対応するハッシュはクライアントの裁量で、存在しないか、あるいは、その証明書もしくは証明書チェーンの SHA-1ハッシュであるか、 のいずれかとなる。(X.509 証明書の場合、DER で符号化された証明書 もしくは DER で符号化された PkiPath)。

「X.509 証明書について、URL の一覧が使われているとき、URL の順序は、TLS 証明書メッセージ ([RFC5246 の 7.4.2 節を参照)において使われているものと同様であるが、証明書が PkiPath において符号化されている順序とは逆であること」に注意。いずれの場合においても、自己署名された ルート証明書は、「そのサーバは、それを検証するために、既に保持していなければならない」という想定のもとで、そのチェーンから削られる可能性がある(MAY)

"CertificateURL" を受け取るサーバは、クライアントの証明書チェーンをその URL から取得して、それから、いつもどおり、その証明書チェーンを処理することを試みるものとする(SHALL)。そのチェーン中のあらゆる URL のコンテンツのキャッシュされたコピーが、SHA-1 ハッシュがその URL について在り、かつ、それがキャッシュされ複製のハッシュと一致する場合、使われる可能性がある(MAY)

この拡張をサポートするサーバは、証明書 URL について http: URL スキームをサポートしなければならない(MUST)。そして、他のスキームをサポートする可能性がある(MAY)。"http"、"https" もしくは "ftp" 以外のスキームの利用は、予期されない問題を作り出す可能性がある。

使われているプロトコルが HTTP である場合、その HTTP サーバは、Cache-Control を使うように設定され、「証明書もしくは証明書チェーンは、キャッシュされる必要があるか否か?」と「どれだけの期間、キャッシュされる必要があるか?」を規定するために [RFC2616] に記述されているダイレクティブ(directives)を無効にしうる。

その TLS サーバは、証明書もしくは証明書のチェーンを受け取るとき、HTTP リダイレクト(redirect)に従ってはならない(MUST NOT)。この拡張において使われる URL は、このようなリダイレクト(redirect)に依存することを選択してはならない(MUST NOT)。

そのプロトコルが証明書を取得するために使われる場合、もしくは、証明書チェーンがHTTP が行うように)MIME-formatted response を返す場合、下記の MIME Content-Types が使われるものとする(SHALL)。: ひとつの X.509v3 証明書が返されるとき、その Content-Type は、"application/pkix-cert" [RFC2585]であり、一連の X.509v3 certificate が返されるとき、その Content-Type は、"application/pkix-pkipath" (10.1節)である。そのサーバは、「(あらゆる MIME コンテンツ転送の符号化をデコードした後に)その URLから取得したオブジェクトのコンテンツの SHA-1 hash が、与えられたハッシュと一致すること」をチェックしなければならない(MUST)。取得されたいかなるオブジェクトも正しい SHA-1 ハッシュをもたない場合、そのサーバは、そのハンドシェイクを bad_certificate_hash_value(114) alert と共に中断しなければならない(MUST)。この alert は、常に fatal である。

クライアントは、"Certificate" か、あるいは、(証明書の URL を送るためのオプションを成功裏に交渉した後に)"CertificateURL" のいずれかを送ることを選択する可能性がある。証明書を送るためのオプションが、複数の証明書を保持するクライアントに柔軟性を提供するために含められる。

あるサーバが与えられた CertificateURL 中の証明書を取得できない場合、サーバがハンドシェイクを完結させるために証明書を要求するのであれば、それは、fatal certificate_unobtainable(111) alert を送らなければならない(MUST)。そのサーバが証明書を要求しない場合、そのサーバは、そのハンドシェイクを継続する。そのサーバは、その場合、warning-level alert を送る可能性がある(MAY)。そのような alert を受け取るクライアントは、その alert を記録し、可能であれば、そのハンドシェイクで続行する必要がある(SHOULD)

6. Trusted CA 表示 English

メモリ制約に起因して、少数の CA ルート鍵しか保持しない制約のあるクライアントは、繰り返されるハンドシェイクの失敗(failure)を避けるために、サーバ宛に「どの ルート鍵を保持しているか?」を示すことを望む可能性がある。

「クライアントは、どの CA ルート鍵を保持するか?」を示すために、クライアントは、(拡張された) クライアント hello 中に 種別が "trusted_ca_keys" の拡張を含む可能性がある(MAY)。この拡張の "extension_data" フィールドは、"TrustedAuthorities" を含むものとする(SHALL)。これは、下記のとおり。:

      struct {
          TrustedAuthority trusted_authorities_list<0..2^16-1>;
      } TrustedAuthorities;
      struct {
          IdentifierType identifier_type;
          select (identifier_type) {
              case pre_agreed: struct {};
              case key_sha1_hash: SHA1Hash;
              case x509_name: DistinguishedName;
              case cert_sha1_hash: SHA1Hash;
          } identifier;
      } TrustedAuthority;
      enum {
          pre_agreed(0), key_sha1_hash(1), x509_name(2),
          cert_sha1_hash(3), (255)
      } IdentifierType;
      opaque DistinguishedName<1..2^16-1>;

ここで、"TrustedAuthorities" は、クライアントが処理する CA ルート鍵識別子(identifier)の一覧を提供する。各 CA ルート鍵は、下記のいずれかを通じて識別される。:

「クライアントは、この拡張中にクライアントが保持する CA ルート鍵を含まない、あるいは、いくらか、もしくは、すべてを含む可能性があること」に注意。

「鍵ハッシュ、もしくは、単体の Distinguished Name は、証明書の発行者を一意に識別しない可能性があること(例えば、特定の CA が複数の鍵ペアをもつ場合)」にも注意。しかし、ここで、我々は、「これは、TLS において証明書発行者を識別するための Distinguished Names の用法に従う場合である」と想定する。

CA ルート鍵を含めないオプションは、そのクライアントが何らか事前定義された一式の CA ルート鍵の保持を示すことができるようにするために含められる。

"trusted_ca_keys" 拡張を納める クライアント hello を受け取るサーバは、そのクライアント宛に返す適切な証明書チェーンの選択をガイドするために、その拡張中に納められた情報を使う可能性がある(MAY)。この際には、そのサーバは、(拡張された)server hello 中に種別として"trusted_ca_keys" の拡張を含むものとする(SHALL)。この拡張の"extension_data" フィールドは、空であるものとする(SHALL)

 

7. 切り詰められた HMAC English

現在、定義されている TLS サイファースィートは、MAC construction HMAC [RFC2104] をレコード層の通信を認証する(authenticate)ためにを使う。TLS において、そのハッシュ関数の output 全体が、その MAC tag として使われる。しかし、制約された環境においては、MAC tag をフォーマットに合わせるとき、ハッシュ関数の output を 80 bit に切り詰めることによって、帯域を節約することが渇望される可能性がある。

80 bit に切り詰められた HMAC の利用を交渉するために、クライアントは、拡張された クライアント hello 中に種別が "truncated_hmac" の拡張を含む可能性がある(MAY)。この拡張の "extension_data" フィールドは、空であるものとする(SHALL)

"truncated_hmac" 拡張を納める拡張された hello を受け取るサーバは、種別が "truncated_hmac"の拡張を拡張された サーバ hello 中に空の "extension_data"と共に含めることによって、切り詰められた HMAC を使うことに合意する可能性がある(MAY)

「HMAC を使わない新しいサイファースィートが追加され、そのセッションがこれらのサイファースィートのひとつと交渉する場合、この拡張は影響を与えないこと」に注意。「他の MAC を使うあらゆる新しいサイファースィートは、セキュリティと帯域についての考慮事項の両方を考慮して、MAC 長を、そのサイファースィート定義の不可欠(integral)な部分と見なすこと」が強く推奨される。

HMAC の切り詰めが TLS ハンドシェイク において成功裡に交渉されていて、かつ、交渉されたサイファーが HMAC を使う場合、そのクライアントとサーバの両方は、この事実を他の交渉されたセキュリティパラメータと共に TLS レコード層に渡す。したがって、そのセッションにおいて、クライアントおよびサーバは、[RFC2104] に規定されているように、計算された切り詰められた HMAC を使わなければならない(MUST)。すなわち、CipherSpec.hash_size は、10 byte であり、その HMAC output の最初の 10 byte のみが、転送されて、チェックされる。「この拡張は、ハンドシェイク過程もしくは鍵導出の一部として、PRF(pseudo-random function)の計算に影響を与えないこと」に注意。

交渉された HMAC の切り詰め(truncation)長(size)は、セッション回復(resumption)を含むセッションの継続(duration)に適用する。

 

8. 証明書状態リクエスト English

制約された(constrained)クライアントは、CRL の転送を避け、それによって、制約されたネットワーク上の帯域を節約するために、サーバ証明書の有効性(validity)をチェックするために OCSP [RFC2560] のような証明書状態プロトコルを使うことを望む可能性がある。この拡張は、TLS ハンドシェイクにおいて、このような情報が通信遅延(roundtrip)や資源を節約して送られうるようにする。

証明書 status 情報を受け取るクライアントの渇望を示すために、クライアントは、(拡張された)クライアント hello 中に種別が "status_request" の拡張を含む可能性がある(MAY)。この拡張の"extension_data" フィールドは、"CertificateStatusRequest" を含むものとする(SHALL)。ここでは、下記の処理が行われる。:

      struct {
          CertificateStatusType status_type;
          select (status_type) {
              case ocsp: OCSPStatusRequest;
          } request;
      } CertificateStatusRequest;
      enum { ocsp(1), (255) } CertificateStatusType;
      struct {
          ResponderID responder_id_list<0..2^16-1>;
          Extensions  request_extensions;
      } OCSPStatusRequest;
      opaque ResponderID<1..2^16-1>;
      opaque Extensions<0..2^16-1>;

OCSPStatusRequest において、"ResponderIDs" は、そのクライアントが信頼する OCSP responder の一覧を提供する。ゼロ長の "responder_id_list" sequence は、「その responder は、そのサーバに黙示的に知られている(例: 事前の調整(arrangement)によって)」という特別な意味をもつ。"Extensions" は、OCSP リクエスト拡張を DER で符号化したものである。

"ResponderID" および "Extensions" の両方は、[RFC2560]定義されているように、DER で符号化された ASN.1 type である。英単語の "Extensions(拡張)" は、[RFC5280]から導入された。ゼロ長の "request_extensions"値は、「("Extensions" 種別としては妥当ではないゼロ長の ASN.1 SEQUENCE とは逆に)拡張は無いこと」を意味する。

"id-pkix-ocsp-nonce" OCSP 拡張の場合、[RFC2560] は、その符号化について不明確である。明確化すると、この nonce は、別の OCTET STRING としてカプセル化される DER で符号化された OCTET STRING でなければならない(MUST)(「既存の OCSP クライアントに基づく実装は、この要件への準拠性についてチェックされる必要があること」に注意)。

"status_request" 拡張を納める クライアント hello を受け取るサーバは、適切な証明書状態レスポンスを、それらの証明書と共にクライアント宛に返す可能性がある(MAY)。OCSP が要求される場合、それらは、OCSP responder を選択するとき、その拡張中に格納された情報を使う必要があり(SHOULD)、request_extensions を、その OCSP リクエスト中に含む必要がある(SHOULD)

サーバは、"CertificateStatus" メッセージを "Certificate" メッセージの直後(かつ、あらゆる "ServerKeyExchange" メッセージ、もしくは"CertificateRequest" メッセージの前)に送ることによって、サーバ証明書と共に証明書レスポンスを返す。サーバが "CertificateStatus" メッセージを返す場合、そのサーバは、拡張された server hello 中に空の "extension_data" と共に種別が "status_request" の拡張を含めていなければならない(MUST)。"CertificateStatus" メッセージは、下記のように、ハンドシェイク メッセージ種別 "certificate_status" を使って運ばれる(2章も参照)。:

      struct {
          CertificateStatusType status_type;
          select (status_type) {
              case ocsp: OCSPResponse;
          } response;
      } CertificateStatus;
      opaque OCSPResponse<1..2^24-1>;

"ocsp_response" は、完全な、DER で符号化された OCSP レスポンスを( [RFC2560] において定義されている ASN.1 表記の OCSPレスポンスを使って)納める。「ひとつの OCSP レスポンスのみが送られる可能性がある。

「サーバは、たとえ クライアント hello メッセージ中の "status_request" 拡張を受け取る場合でも、"CertificateStatus" メッセージを送らないことも選択する可能性もある(MAY)こと」に注意。

「サーバは、client hello メッセージ中の "status_request" 拡張を受け取らない限り、"CertificateStatus" メッセージを送らなければならない(MUST NOT )こと」にも注意。

OCSP レスポンスを要求して、"CertificateStatus" メッセージ中の OCSP レスポンスを受け取るクライアントは、その OCSP レスポンスをチェックして、その レスポンスが十分なもの(satisfactory)でない場合、そのハンドシェイクを中止しなければならない(MUST)。この警告は、常に fatal である。

9. エラー警告 English

4 つの新しいエラー警告が、本書中に規定されている TLS 拡張についての用法のために定義されている。既存のクライアントやサーバが "breaking" を避けるために、これらの警告は、その送信者が通信相手から extended hello メッセージを受け取ったのでない限り、送られてはならない(MUST NOT)。これらのエラー警告は、下記の構文(syntax)を使って運ばれる。新しい警告は、エラー alert 番号と同じ行上のコメントによって示されているように、最後の4つである。

      enum {
          close_notify(0),
          unexpected_message(10),
          bad_record_mac(20),
          decryption_failed(21),
          record_overflow(22),
          decompression_failure(30),
          handshake_failure(40),
          /* 41 は、経緯上の理由で定義されていない。 */
          bad_certificate(42),
          unsupported_certificate(43),
          certificate_revoked(44),
          certificate_expired(45),
          certificate_unknown(46),
          illegal_parameter(47),
          unknown_ca(48),
          access_denied(49),
          decode_error(50),
          decrypt_error(51),
          export_restriction(60),
          protocol_version(70),
          insufficient_security(71),
internal_error(80), user_canceled(90), no_renegotiation(100), unsupported_extension(110), certificate_unobtainable(111), /* 新 */ unrecognized_name(112), /* 新 */ bad_certificate_status_response(113), /* 新 */ bad_certificate_hash_value(114), /* 新 */ (255) } AlertDescription;
 
"certificate_unobtainable" は、5章に記述されている。
"unrecognized_name" は、3章に記述されている。
"bad_certificate_status_response" は、8章に記述されている。
"bad_certificate_hash_value" は、5章に記述されている。
10. IANA に関する考慮事項 English

TLS 拡張と、registry の creation についての IANA 考慮事項は、後述する MIME type application/pkix-pkipath の登録を除いて、[RFC5246] の 12章に網羅されいる。

IANA TLS 拡張と、RFC 4366 を参照している MIME type application/pkix-pkipath registry entries は、本書を参照するように更新されている。

10.1. pkipath MIME 種別登録 English

MIME media type name: application
MIME subtype name: pkix-pkipath
Required parameters: none

Optional parameters: バージョン(デフォルト値は "1")

Encoding considerations:

Binary; this MIME type is a DER encoding of the ASN.1 type
PkiPath, 下記のように定義される:
 PkiPath ::= SEQUENCE OF Certificate
 PkiPath は、証明書パスを表現するために使われる。このシーケンス内において、証明書の順序は、「最初の証明書のサブジェクトは、2番目の証明書の発行者となり…」というようなものとなる。
これは、[X509-4th-TC1] 中に公表されている定義と同一のものである。「これは、[X509-4th]」中のものとは異なること」に注意。

すべての証明書は、[RFC5280] に準拠しなければならない(MUST)。(これは、この種別を使う PKIX 準拠証明書のみを符号化するための要件として解釈される必要がある。あらゆるこのような証明書がもたらすセキュリティの結末は、注意深く考慮される必要があるが、これは、必ずしも「厳密には PKIX に準拠していない証明書のすべてが、依拠当事者(relying party)によって棄却されなければならないこと」までは要求しない。)

DER (as opposed to BER) encoding が使われなければならない(MUST)。この種別が 7-bit transport 上を送られる場合、base64 encoding が使われる必要がある( SHOULD)

Security considerations:

[X509-4th] と [RFC5280](もしくは、これらに対するあらゆる更新RFC)の「セキュリティについての考慮事項」が、この種別 (例: TLS)を使うあらゆるプロトコルについてのものと共に適用される。

「この種別は、署名検証者(relying party)の既存の trusted CA の設定に関する妥当性(validity)について関連付けられうる証明書チェーンのみを規定すること」、「これは、その設定に対するいかなる変更を規定するためにも使われることを意図されていないこと」に注意。

Interoperability considerations:

この種別について、特定の相互運用可能性問題は知られていないが、一般的な X.509 証明書に関する推奨事項については、[RFC5280] を参照。

Published specification: 本書と [RFC5280]。

Applications that use this media type:

TLS。これは、他のプロトコルによって、あるいは、 PKIX 証明書チェーンの一般的な交換のためも使われる可能性がある。

Additional information:

Magic number(s): DER-encoded ASN.1 は、容易に解釈されうる。
 Further parsing が、これを他の ASN.1 種別から区別するために要求される。
File extension(s): .pkipath
Macintosh File Type Code(s): 規定されていない

Person & email address to contact for further information:

Magnus Nystrom

Intended usage: COMMON

Change controller: IESG

10.2. TLS 警告、TLS HandshakeTypes および’ ExtensionTypes への参照 English

TLS Alert Registry 中の下記の値は、本書を参照するように更新されている。:

111 certificate_unobtainable
112 unrecognized_name
113 bad_certificate_status_response
114 bad_certificate_hash_value

TLS HandshakeType Registry 中の記の値は、本書を参照するように更新されている。:

21 certificate_url
22 certificate_status

下記の ExtensionType 値は、本書を参照するように更新されている。:

0 server_name
1 max_fragment_length
2 client_certificate_url
3 trusted_ca_keys
4 truncated_hmac
5 status_request

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

TLS 拡張についての一般的なセキュリティについての考慮事項は、[RFC5246] が対応している。本書において規定されている特定の拡張についての セキュリティの考慮事項は、後述される。

一般に、実装者は、脅威の動向(the state of the art)を監視することを続け、識別されたあらゆる弱点に対応する必要がある。

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

単一のサーバが複数のドメインをホストする場合、明らかに、各ドメインのオーナーにとっては「これ(サーバ)が、セキュリティニーズを満たすこと」を確保することが必要不可欠である。これとは別に、server_name は、顕著なセキュリティ論点をもたらすようには現れない。

あるクライアントが、そのアプリケーションプロトコルにおいて異なる server_name を提示する可能性があるので、これらの名前が同一であることに依存するアプリケーションサーバの実装は、「そのクライアントは、そのアプリケーションプロトコル内で異なる名前を提供しなかったこと」を確保するためにチェックしなければならない(MUST)

実装は、「server_name 中の length フィールドの値がどのようなものであれ、バッファオーバーフローが起こらないこと」を確保しなければならない(MUST)

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

最大フラグメント長は、ハンドシェイクメッセージを含めて、ただちに影響を与える。しかし、それは、TLS には無い、いかなるセキュリティの複雑な事項(complication)も持ち込まない。なぜならば、TLS は、実装にフラグメント化されたハンドシェイクメッセージを扱えることを要求するからである。

「4章に記述されているように、ひとたび、非 null のサイファースィートが活性化されると、有効な(effective)最大フラグメント長は、交渉された max_fragment_length と共に、そのサイファースィートおよび圧縮方法に依存すること」に注意。これは、バッファの大きさを測るとき、そしてバッファオーバーフローについてチェックするとき、考慮されなければならない。

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

client_certificate_url についてのサポートは、別の URL プロトコルにおけるクライアントとしてふるまうサーバを巻き込む。 それゆえ、そのサーバは、その URL スキームのクライアントが対象となるの同様の「セキュリティについての考慮事項」の多くの対象となるが、「クライアントは、そのサーバ宛に、どこかの(おそらく、つながっているように見える)URL に接続することを知らせることを試みる」という追加された関心事を伴う。

一般に、この論点は、「攻撃者は、そのサーバを、何らかのセキュリティの欠陥について、脆弱である別のホストを間接的に攻撃するために使う可能性があること」を意味する。これは、サービス妨害攻撃の可能性ももたらす。ここでは、攻撃者は、そのサーバ宛に多くの接続(connection)を作る。その各々は、「その攻撃の標的宛に、そのサーバが試みる接続」をもたらす。

「そのサーバは、ファイアウォールの背後に在る可能性があること、あるいは、さもなければ、公衆インターネットから直接のアクセスは不可能なホストにアクセスできること」に注意。これは、上記の潜在的なセキュリティ問題であったり、サービス妨害問題を実行可能であると共に、さもなければ隠されていたであろう内部ホストの存在を確認できるようにする可能性がある。

含まれる詳細なセキュリティの関心事は、そのサーバによってサポートされている URL スキームに依存する。HTTP の場合、その関心事は、公衆がアクセス可能な HTTP プロキシサーバに適用されるものと同様である。HTTPS の場合、ループ(loop)およびデッドロック(deadlock)が作り出される可能性があり、これは、対応される必要がある。FTP の場合、攻撃が発生する。これは、FTP bounce 攻撃と同様のものである。

この論点の結果として、「client_certificate_url 拡張は、デフォルトで有効化されているのではなく、サーバ運用管理者によって特定して有効にされる必要があること」が推奨される(RECOMMENDED)。「URI プロトコルは、その運用管理者によって個別に有効にされ、最小セットのプロトコルのみが有効にされこと」も推奨される(RECOMMENDED)。限られたセキュリティしか提供しない特殊な(unusual)プロトコル、もしくは、そのセキュリティがよく理解されていない特殊な(unusual)プロトコルは、避けられる必要がある(SHOULD)

[RFC3986] において検討されているように、デフォルト以外のポートを規定する URL は、とても長い URL が問題をもたらす可能性があるのと同様に、問題をもたらす可能性がある。(これは、バッファオーバーフロー脆弱性を攻略する際に有用となってしまう可能性が、より高い。)

この拡張は、(RFC 4366 にあるように)SHA-1 を使い続け、アルゴリズムの交換可能性(agility)を提供しない。この場合、SHA-1 に要求された属性は、第二原像攻撃耐性であり、衝突攻撃耐性ではない。さらに、たとえ将来、SHA-1 に対する第二原像攻撃が可能とされた(found)場合でも、client_certificate_url に対する攻撃は、サーバによって妥当な証明書として受容されて、同一の公開鍵を含む第二原像を要求する。

「HTTP caching プロキシは、インターネット上で卑近であり、プロキシには最新バージョンの object について、正しくチェックしないものがあること」にも注意。HTTP(もしくは別のキャッシュを行うプロトコル)を使っている リクエストが誤設定されたプロクシ(もしくは、壊れたプロキシ)を通過する場合、そのプロキシは、期限切れの(out-of-date)レスポンスを返す可能性がある。

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

「どの CA ルート鍵をクライアントが保持しているかは、機密情報と見なされうる」可能性がある。結果として、CA ルート鍵表示拡張は、注意を払って使われる必要がある。

SHA-1 証明書ハッシュ代替(alternative)の利用は、「各証明書は、明確に(unambiguously)規定されること」を確保する。以前の拡張に関して、MD5 と SHA-1 ハッシュの両方を使うことが必要不可欠とは信じられていなかった。

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

「切り詰められた MAC は、『切り詰められていない』 MAC よりも弱い」という可能性がある。しかし、 MD5 もしくは SHA-1 で 80 bit に切り詰められた HMAC について、顕著な弱点は、現在、知られていないか、あるいは、存在することが予想されている。

「MAC の output 長は、MAC 値の偽造(forging)は、オフラインではできないので、公開鍵暗号技術の鍵ほどの長さである必要はない。: TLS において、1 回の失敗した(failed)MAC 推測(guess)が、その TLS セッションの即刻切断(immediate termination)を引き起こすこと」に注意。

その MAC アルゴリズムは、すべてのハンドシェイクメッセージの後でのみ、影響を与えるので、能動的(active)な攻撃者が切り詰められた HMAC 拡張の交渉を、切り詰められた HMAC 拡張が使われないところに(「そのハンドシェイク認証(authentication)は、セキュアである」という程度までに)強要することは、不可能である。すべてのハンドシェイクメッセージは、「拡張パラメータが Finished メッセージ中のハッシュによって認証されている」ということに影響を与える。それゆえ、将来、何らかのセキュリティ問題が「切り詰められた HMAC」について見つかった際には、あるセッションについて、クライアントかサーバのいずれかが、その問題を考慮して更新された場合、この拡張の利用を拒否することは可能である。

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

あるクライアントが OCSP レスポンスを要求する場合、クライアントは、「侵害された(compromised)鍵を使う攻撃者のサーバは、その拡張をサポートしないふりをする(そして、おそらく)可能性があること」を考慮しなければならない。この場合、証明書の OCSP 検証(validation)を要求するクライアントは、その OCSP サーバに直接、問い合わせるか、あるいは、そのハンドシェイクを中止するか、いずれかを行う必要がある(SHOULD)

OCSP nonce リクエスト拡張(id-pkix-ocsp-nonce)の使用は、OCSP レスポンスを再生することを試みる攻撃に対するセキュリティを改善する可能性がある。詳細については、[RFC2560] の 4.4.1節を参照。

 

12. 規範的参考文献
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti,
"HMAC: Keyed-Hashing for Message Authentication",
RFC 2104, 1997年 2月.
[RFC2119] Bradner, S.,
"Key words for use in RFCs to Indicate Requirement Levels",
BCP 14, RFC 2119, 1997年 3月.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams,
"X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP",
RFC 2560, 1999年 6月.
[RFC2585] Housley, R. and P. Hoffman,
"Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP",
RFC 2585, 1999年 6月.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee,
"Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2616, 1999年 6月.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax",
STD 66, RFC 3986, 2005年 1月.
[RFC5246] Dierks, T. and E. Rescorla,
"The Transport Layer Security (TLS) Protocol Version 1.2",
RFC 5246, 2008年 8月.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk,
"Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile",
RFC 5280, 2008年 5月.
[RFC5890] Klensin, J.,
"Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework",
RFC 5890, 2010年 8月.


13. 参考情報

[RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)",
RFC 2712, 1999年10月.
[X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001,
"Information Systems - Open Systems Interconnection - The Directory: Public key and attribute certificate frameworks".
[X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) | ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to ISO/IEC 9594:8:2001.
 
Appendix A. RFC 4366 からの変更点

RFC 4366 と本書の間の顕著な変更点が、後述される。

RFC 4366 は、(TLS ハンドシェイクと、クライアント hallo および サーバ hello について、)一般的な拡張メカニズムと、具体的な拡張の両方を記述していた。RFC 4366 は、RFC 4346: TLS 1.1 と関連づけられていた。クライアントとサーバの hello 拡張メカニズムは、RFC 5246: TLS 1.2 に移されている。それゆえ、RFC 5246 と関連づけれらている本書は、ハンドシェイク 拡張メカニズムと、RFC 4366 からの特定の拡張のみを含む。RFC 5246 は、「unknown 拡張エラーと新しい拡張仕様についての考慮事項」も規定している。それゆえ、その題材は、本書から削除されている。

サーバ名拡張は、今や、ASCII 表記のみを規定しており、UTF-8 を排している。「ServerNameList が、あらゆる特定の name_type の複数の名前を含むことができること」がもたらされている。あるサーバ名が提供されながら解釈できない場合、そのサーバは、エラー無しにそのハンドシェイクを続けるか、あるいは、fatal エラーを送るか、のいずれかの必要がある。warning-level メッセージを送ることは、クライアントのふるまいが予測不能(unpredictable)になるので推奨されない。「あるセッションを再開するか否か?」を判断する際に server_name 拡張を使うユーザについての規定が追加された。さらに、この拡張は、そのセッションを確立したフル(full)ハンドシェイク内にあったので、ひとつのセッション回復(resumption)リクエスト内において同一である必要がある。このような回復(resumption)リクエストは、その server_name 拡張が異なる場合、受容されてはならないが、代わりに、新しいセッションをできる限り確立するためにフル(full)ハンドシェイクが行われなければならない。

クライアント証明書 URL 拡張は、ハッシュの存在を必須とするために変更されている。

DTLS の事例について、交渉された最長フラグメント長のオーバーフローを報告する要件は、認証(authentication)を渡す際の条件次第(conditional)とされた。

TLS サーバは、今や、証明書を取得するとき、HTTP リダイレクトに従うことは、禁止されている。

また、素材は、軽微なやり方で再編されている。例えば、「どのエラーが fatal であるか?」に関する情報は、「エラー警告」の節から個々の拡張仕様に移されている。


Appendix B.  謝辞

本書は、RFC 4366 からの素材に基づいている。(これについての著者は、S. Blake-Wilson 氏、M. Nystrom 氏、D. Hopwood 氏、J. Mikkelsen 氏、そして T. Wright 氏であった。)他の貢献者には、Joseph Salowey 氏、Alexey Melnikov 氏、Peter Saint-Andre 氏、そして Adrian Farrel 氏が含まれる。

著者のアドレス

Donald Eastlake 3rd
Huawei
155 Beaver Street
Milford, MA 01757 USA

電話: +1-508-333-2270
EMail: d3e3e3@gmail.com

翻訳者のアドレス

独立行政法人 情報処理推進機構
技術本部 セキュリティセンター
宮川 寧夫

EMail: miyakawa@ipa.go.jp