[要約] RFC 5489は、Transport Layer Security (TLS) プロトコルにおけるECDHE_PSK暗号スイートに関する文書です。この文書の目的は、前方秘匿性を提供しつつ、事前共有キー(PSK)を用いた認証メカニズムをサポートするための方法を定義することにあります。これは、特にリソースが限られた環境や、事前共有キーに基づく認証が望ましいシナリオで利用されます。関連するRFCには、TLSの基本を定義するRFC 5246(TLS 1.2)や、PSK認証を扱うRFC 4279があります。ECDHE_PSK暗号スイートは、セキュリティと効率性のバランスを取りながら、TLSセッションの安全性を強化するために設計されています。

Network Working Group                                           M. Badra
Request for Comments: 5489                         CNRS/LIMOS Laboratory
Category: Informational                                        I. Hajjeh
                                                              INEOVATION
                                                              March 2009
        

ECDHE_PSK Cipher Suites for Transport Layer Security (TLS)

ECDHE_PSKトランスポート層セキュリティ(TLS)用の暗号スイート

Status of This Memo

本文書の状態

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。

Copyright Notice

著作権表示

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

Copyright(c)2009 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

このドキュメントは、BCP 78およびこのドキュメントの公開日(http://trustee.ietf.org/license-info)に発効するIETFドキュメントに関連するIETFトラストの法的規定の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部で著作権を管理している人が、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。

Abstract

概要

This document extends RFC 4279, RFC 4492, and RFC 4785 and specifies a set of cipher suites that use a pre-shared key (PSK) to authenticate an Elliptic Curve Diffie-Hellman exchange with Ephemeral keys (ECDHE). These cipher suites provide Perfect Forward Secrecy (PFS).

このドキュメントでは、RFC 4279、RFC 4492、およびRFC 4785を拡張し、事前共有キー(PSK)を使用してエフェメラルキー(ECDHE)との楕円曲線Diffie-Hellman交換を認証する一連の暗号スイートを指定します。これらの暗号スイートは、Perfect Forward Secrecy(PFS)を提供します。

Table of Contents

目次

   1. Introduction ....................................................2
      1.1. Applicability Statement ....................................3
      1.2. Conventions Used in This Document ..........................3
   2. ECDHE_PSK Key Exchange Algorithm ................................3
   3. ECDHE_PSK-Based Cipher Suites ...................................4
      3.1. ECDHE_PSK Cipher Suites Using the SHA-1 Hash ...............4
      3.2. ECDHE_PSK Cipher Suites Using SHA-2 Hashes .................4
   4. ECDHE_PSK-Based Cipher Suites with NULL Encryption ..............5
      4.1. ECDHE_PSK Cipher Suite Using the SHA-1 Hash with
           NULL Encryption ............................................5
      4.2. ECDHE_PSK Cipher Suites Using SHA-2 Hashes with
           NULL Encryption ............................................5
   5. Security Considerations .........................................5
   6. IANA Considerations .............................................6
   7. Acknowledgments .................................................6
   8. Normative References ............................................6
        
1. Introduction
1. はじめに

RFC 4279 specifies cipher suites for supporting TLS using pre-shared symmetric keys that (a) use only symmetric key operations for authentication, (b) use a Diffie-Hellman exchange authenticated with a pre-shared key (PSK), or (c) combine public key authentication of the server with pre-shared key authentication of the client.

RFC 4279は、(a)認証に対称鍵操作のみを使用する、(b)事前共有鍵(PSK)で認証されたDiffie-Hellman交換を使用する、または(c)事前共有対称鍵を使用してTLSをサポートするための暗号スイートを指定していますサーバーの公開鍵認証とクライアントの事前共有鍵認証を組み合わせます。

RFC 4785 specifies authentication-only cipher suites (with no encryption). These cipher suites are useful when authentication and integrity protection is desired, but confidentiality is not needed or not permitted.

RFC 4785は、認証のみの暗号スイート(暗号化なし)を指定しています。これらの暗号スイートは、認証と整合性保護が必要な場合に役立ちますが、機密性は必要ないか、許可されません。

RFC 4492 defines a set of Elliptic Curve Cryptography (ECC)-based cipher suites for TLS and describes the use of ECC certificates for client authentication. In particular, it specifies the use of Elliptic Curve Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism.

RFC 4492は、TLSの一連の楕円曲線暗号(ECC)ベースの暗号スイートを定義し、クライアント認証のためのECC証明書の使用について説明しています。特に、TLSハンドシェイクでの楕円曲線Diffie-Hellman(ECDH)鍵合意の使用と、新しい認証メカニズムとしての楕円曲線デジタル署名アルゴリズム(ECDSA)の使用を指定しています。

This document specifies a set of cipher suites that use a PSK to authenticate an ECDH exchange. These cipher suites provide Perfect Forward Secrecy. Some of these cipher suites provide authentication only.

このドキュメントでは、PSKを使用してECDH交換を認証する一連の暗号スイートを指定します。これらの暗号スイートは、Perfect Forward Secrecyを提供します。これらの暗号スイートの一部は、認証のみを提供します。

The reader is expected to become familiar with RFC 4279, RFC 4492, and RFC 4785 prior to studying this document.

読者は、このドキュメントを読む前に、RFC 4279、RFC 4492、およびRFC 4785に精通している必要があります。

1.1. Applicability Statement
1.1. 適用性ステートメント

The cipher suites defined in this document can be negotiated, whatever the negotiated TLS version is.

このドキュメントで定義されている暗号スイートは、ネゴシエートされたTLSバージョンが何であれ、ネゴシエートできます。

The applicability statement in [RFC4279] applies to this document as well.

[RFC4279]の適用性に関する記述は、このドキュメントにも適用されます。

1.2. Conventions Used in This Document
1.2. このドキュメントで使用される規則

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

2. ECDHE_PSK Key Exchange Algorithm
2. ECDHE_PSK鍵交換アルゴリズム

The cipher suites described in this document make use of the elliptic curve (EC) parameter negotiation mechanism defined in RFC 4492. When the cipher suites defined in this document are used, the 'ec_diffie_hellman_psk' case inside the ServerKeyExchange and ClientKeyExchange structure MUST be used instead of the 'psk' case defined in [RFC4279] (i.e., the ServerKeyExchange and ClientKeyExchange messages include the EC Diffie-Hellman parameters in the form specified in Sections 5.4 and 5.7 of [RFC4492]). The PSK identity and identity hint fields have the same meaning and encoding as specified in [RFC4279] (note that the ServerKeyExchange message is always sent, even if no PSK identity hint is provided).

このドキュメントで説明されている暗号スイートは、RFC 4492で定義されている楕円曲線(EC)パラメータネゴシエーションメカニズムを利用しています。このドキュメントで定義されている暗号スイートを使用する場合、ServerKeyExchangeおよびClientKeyExchange構造内の「ec_diffie_hellman_psk」ケースを代わりに使用する必要があります[RFC4279]で定義された「psk」ケースの例(つまり、ServerKeyExchangeおよびClientKeyExchangeメッセージには、[RFC4492]のセクション5.4および5.7で指定された形式のEC Diffie-Hellmanパラメータが含まれます)。 PSK IDおよびIDヒントフィールドは、[RFC4279]で指定されたものと同じ意味およびエンコーディングを持っています(PSK IDヒントが提供されていない場合でも、ServerKeyExchangeメッセージは常に送信されることに注意してください)。

The format of the ServerKeyExchange and ClientKeyExchange messages is shown below.

ServerKeyExchangeおよびClientKeyExchangeメッセージの形式を以下に示します。

      struct {
          select (KeyExchangeAlgorithm) {
              /* other cases for rsa, diffie_hellman, etc. */
              case ec_diffie_hellman_psk:  /* NEW */
                  opaque psk_identity_hint<0..2^16-1>;
                  ServerECDHParams params;
          };
      } ServerKeyExchange;
        
      struct {
          select (KeyExchangeAlgorithm) {
              /* other cases for rsa, diffie_hellman, etc. */
              case ec_diffie_hellman_psk:   /* NEW */
                  opaque psk_identity<0..2^16-1>;
                  ClientECDiffieHellmanPublic public;
          } exchange_keys;
      } ClientKeyExchange;
        

The premaster secret is formed as follows. First, perform the ECDH computation as described in Section 5.10 of [RFC4492]. Let Z be the octet string produced by this computation. Next, concatenate a uint16 containing the length of Z (in octets), Z itself, a uint16 containing the length of the PSK (in octets), and the PSK itself.

プリマスターシークレットは次のように形成されます。最初に、[RFC4492]のセクション5.10の説明に従ってECDH計算を実行します。 Zをこの計算によって生成されたオクテット文字列とします。次に、Z(オクテット単位)の長さを含むuint16、Z自体、PSK(オクテット単位)の長さを含むuint16、およびPSK自体を連結します。

This corresponds to the general structure for the premaster secrets (see Note 1 in Section 2 of [RFC4279]), with "other_secret" containing Z.

これは、プリマスターシークレットの一般的な構造に対応し([RFC4279]のセクション2の注1を参照)、「other_secret」にZが含まれています。

      struct {
          opaque other_secret<0..2^16-1>;
          opaque psk<0..2^16-1>;
      };
        
3. ECDHE_PSK-Based Cipher Suites
3. ECDHE_PSKベースの暗号スイート
3.1. ECDHE_PSK Cipher Suites Using the SHA-1 Hash
3.1. SHA-1ハッシュを使用したECDHE_PSK暗号スイート
      CipherSuite TLS_ECDHE_PSK_WITH_RC4_128_SHA          = {0xC0,0x33};
      CipherSuite TLS_ECDHE_PSK_WITH_3DES_EDE_CBC_SHA     = {0xC0,0x34};
      CipherSuite TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA      = {0xC0,0x35};
      CipherSuite TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA      = {0xC0,0x36};
        

The above four cipher suites match the cipher suites defined in [RFC4279], except that they use an Elliptic Curve Diffie-Hellman exchange [RFC4492] authenticated with a PSK, and:

上記の4つの暗号スイートは、PSKで認証された楕円曲線Diffie-Hellman交換[RFC4492]を使用することを除いて、[RFC4279]で定義された暗号スイートと一致します。

o The Message Authentication Code (MAC) is the Hashed Message Authentication Code (HMAC) [RFC2104] with SHA-1 as the hash function.

o メッセージ認証コード(MAC)は、ハッシュ関数としてSHA-1を使用したハッシュメッセージ認証コード(HMAC)[RFC2104]です。

o When negotiated in a version of TLS prior to 1.2, the Pseudo-Random Function (PRF) from that version is used; otherwise, the PRF is the TLS PRF [RFC5246] with SHA-256 as the hash function.

o 1.2より前のバージョンのTLSでネゴシエートされた場合、そのバージョンの疑似ランダム関数(PRF)が使用されます。それ以外の場合、PRFは、ハッシュ関数としてSHA-256を使用したTLS PRF [RFC5246]です。

3.2. ECDHE_PSK Cipher Suites Using SHA-2 Hashes
3.2. SHA-2ハッシュを使用したECDHE_PSK暗号スイート
      CipherSuite TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256   = {0xC0,0x37};
      CipherSuite TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384   = {0xC0,0x38};
        

The above two cipher suites are the same as the corresponding Advanced Encryption Standard (AES) cipher suites in Section 3.1 above, except for the hash and PRF algorithms, which SHALL be as follows: o For the cipher suite TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256:

上記の2つの暗号スイートは、ハッシュおよびPRFアルゴリズムを除いて、上記のセクション3.1の対応するAdvanced Encryption Standard(AES)暗号スイートと同じです。これは、以下のようにする必要があります。

* The MAC is HMAC [RFC2104] with SHA-256 as the hash function.

* MACはHMAC [RFC2104]で、ハッシュ関数としてSHA-256が使用されています。

* When negotiated in a version of TLS prior to 1.2, the PRF from that version is used; otherwise, the PRF is the TLS PRF [RFC5246] with SHA-256 as the hash function.

* 1.2より前のバージョンのTLSでネゴシエートされた場合、そのバージョンのPRFが使用されます。それ以外の場合、PRFは、ハッシュ関数としてSHA-256を使用したTLS PRF [RFC5246]です。

o For the cipher suite TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384:

o 暗号スイートTLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384の場合:

* The MAC is HMAC [RFC2104] with SHA-384 as the hash function.

* MACはHMAC [RFC2104]で、ハッシュ関数としてSHA-384を使用します。

* When negotiated in a version of TLS prior to 1.2, the PRF from that version is used; otherwise the PRF is the TLS PRF [RFC5246] with SHA-384 as the hash function.

* 1.2より前のバージョンのTLSでネゴシエートされた場合、そのバージョンのPRFが使用されます。それ以外の場合、PRFは、ハッシュ関数としてSHA-384を使用したTLS PRF [RFC5246]です。

4. ECDHE_PSK-Based Cipher Suites with NULL Encryption
4. NULL暗号化を使用するECDHE_PSKベースの暗号スイート
4.1. ECDHE_PSK Cipher Suite Using the SHA-1 Hash with NULL Encryption
4.1. NULL暗号化でSHA-1ハッシュを使用するECDHE_PSK暗号スイート

The following cipher suite matches the cipher suites defined in Section 3.1, except that we define a suite with NULL encryption.

次の暗号スイートは、セクション3.1で定義された暗号スイートと一致しますが、NULL暗号化でスイートを定義する点が異なります。

      CipherSuite TLS_ECDHE_PSK_WITH_NULL_SHA             = {0xC0,0x39};
        
4.2. ECDHE_PSK Cipher Suites Using SHA-2 Hashes with NULL Encryption
4.2. NULL暗号化でSHA-2ハッシュを使用するECDHE_PSK暗号スイート

The following two cipher suites are the same as the corresponding cipher suites in Section 3.2, but with NULL encryption (instead of AES).

次の2つの暗号スイートは、セクション3.2の対応する暗号スイートと同じですが、(AESの代わりに)NULL暗号化を使用しています。

      CipherSuite TLS_ECDHE_PSK_WITH_NULL_SHA256          = {0xC0,0x3A};
      CipherSuite TLS_ECDHE_PSK_WITH_NULL_SHA384          = {0xC0,0x3B};
        
5. Security Considerations
5. セキュリティに関する考慮事項

The security considerations described throughout [RFC5246], [RFC4785], [RFC4492], and [RFC4279] apply here as well. In particular, as the authentication-only cipher suites (with no encryption) defined here do not support confidentiality, care should be taken not to send sensitive information (such as passwords) over connections protected with one of the cipher suites with NULL encryption defined in Section 4 of this document.

[RFC5246]、[RFC4785]、[RFC4492]、および[RFC4279]全体で説明されているセキュリティの考慮事項は、ここにも適用されます。特に、ここで定義されている認証のみの暗号スイート(暗号化なし)は機密性をサポートしていないので、NULL暗号化が定義された暗号スイートの1つで保護された接続を介して、機密情報(パスワードなど)を送信しないように注意する必要があります。このドキュメントのセクション4。

Implementers and administrators should monitor the general statements on recommended cryptographic algorithms (e.g., SHA-1 hash function) that are published from time to time by various forums, including the IETF, as a base for the portfolio they support and the policies for strength of function acceptable for the cipher suites they set.

実装者と管理者は、IETFを含むさまざまなフォーラムによって随時公開されている、推奨される暗号アルゴリズム(SHA-1ハッシュ関数など)に関する一般的な声明を、サポートするポートフォリオと強さのポリシーのベースとして監視する必要があります。彼らが設定した暗号スイートに受け入れられる機能。

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

This document defines the following new cipher suites, whose values have been assigned from the TLS Cipher Suite registry defined in [RFC5246].

このドキュメントでは、次の新しい暗号スイートを定義しています。これらの値は、[RFC5246]で定義されているTLS暗号スイートレジストリから割り当てられています。

      CipherSuite TLS_ECDHE_PSK_WITH_RC4_128_SHA          = {0xC0,0x33};
      CipherSuite TLS_ECDHE_PSK_WITH_3DES_EDE_CBC_SHA     = {0xC0,0x34};
      CipherSuite TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA      = {0xC0,0x35};
      CipherSuite TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA      = {0xC0,0x36};
      CipherSuite TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256   = {0xC0,0x37};
      CipherSuite TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384   = {0xC0,0x38};
      CipherSuite TLS_ECDHE_PSK_WITH_NULL_SHA             = {0xC0,0x39};
      CipherSuite TLS_ECDHE_PSK_WITH_NULL_SHA256          = {0xC0,0x3A};
      CipherSuite TLS_ECDHE_PSK_WITH_NULL_SHA384          = {0xC0,0x3B};
        
7. Acknowledgments
7. 謝辞

The author appreciates Alfred Hoenes for his detailed review and effort on resolving issues in discussion. The author would like to acknowledge Bodo Moeller, Simon Josefsson, Uri Blumenthal, Pasi Eronen, Paul Hoffman, Joseph Salowey, Mark Tillinghast, and the TLS mailing list members for their comments on the document.

著者は、議論の問題を解決するための彼の詳細なレビューと努力のためにアルフレッド・ホーネスに感謝します。著者は、ドキュメントへのコメントについて、Bodo Moeller、Simon Josefsson、Uri Blumenthal、Pasi Eronen、Paul Hoffman、Joseph Salowey、Mark Tillinghast、およびTLSメーリングリストのメンバーに感謝します。

8. Normative References
8. 引用文献

[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.

[RFC2104] Krawczyk、H.、Bellare、M。、および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, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.

[RFC4279] Eronen、P。およびH. Tschofenig、「Pre-Shared Key Ciphersuites for Transport Layer Security(TLS)」、RFC 4279、2005年12月。

[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, May 2006.

[RFC4492] Blake-Wilson、S.、Bolyard、N.、Gupta、V.、Hawk、C。、およびB. Moeller、「Elliptic Curve Cryptography(ECC)Cipher Suites for Transport Layer Security(TLS)」、RFC 4492 、2006年5月。

[RFC4785] Blumenthal, U. and P. Goel, "Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS)", RFC 4785, January 2007.

[RFC4785] Blumenthal、U。およびP. Goel、「トランスポート層セキュリティ(TLS)のNULL暗号化を使用した事前共有キー(PSK)暗号」、RFC 4785、2007年1月。

[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)Protocol Version 1.2」、RFC 5246、2008年8月。

Authors' Addresses

著者のアドレス

Mohamad Badra CNRS/LIMOS Laboratory Campus de cezeaux, Bat. ISIMA Aubiere 63170 France

モハマドバドラCNRS / LIMOS実験室Campus de cezeaux、バット。 ISIMAオビエール63170フランス

   EMail: badra@isima.fr
        

Ibrahim Hajjeh INEOVATION France

イブラヒム・ハジャはフランクを羨望した

   EMail: ibrahim.hajjeh@ineovation.fr