[要約] RFC 4279は、Transport Layer Security (TLS) プロトコルにおいて、事前共有鍵（PSK）を使用する暗号スイートに関する仕様を定義しています。この文書の目的は、TLS接続の認証と暗号化にPSKを利用することで、証明書ベースのメカニズムに代わる選択肢を提供することです。PSKベースの暗号スイートは、証明書の配布や管理が困難または不可能な環境、例えば組み込みシステムや閉じたネットワーク内での利用に特に適しています。関連するRFCには、TLSの基本を定義するRFC 5246（TLS 1.2）や、PSKを利用したTLS 1.3のメカニズムを定義するRFC 8446などがあります。
Network Working Group P. Eronen, Ed.
Request for Comments: 4279 Nokia
Category: Standards Track H. Tschofenig, Ed.
Siemens
December 2005
Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
トランスポート層セキュリティ（TLS）の事前共有鍵暗号スイート
Status of This Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（C）The Internet Society（2005）。
Abstract
概要
This document specifies three sets of new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys (PSKs). These pre-shared keys are symmetric keys, shared in advance among the communicating parties. The first set of ciphersuites uses only symmetric key operations for authentication. The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key, and the third set combines public key authentication of the server with pre-shared key authentication of the client.
このドキュメントでは、事前共有キー（PSK）に基づく認証をサポートするために、トランスポート層セキュリティ（TLS）プロトコルの新しい暗号スイートの3つのセットを指定します。これらの事前共有鍵は対称鍵であり、通信相手間で事前に共有されています。暗号スイートの最初のセットは、認証に対称鍵操作のみを使用します。 2番目のセットは、事前共有キーで認証されたDiffie-Hellman交換を使用し、3番目のセットは、サーバーの公開キー認証とクライアントの事前共有キー認証を組み合わせたものです。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Applicability Statement ....................................3
1.2. Conventions Used in This Document ..........................4
2. PSK Key Exchange Algorithm ......................................4
3. DHE_PSK Key Exchange Algorithm ..................................6
4. RSA_PSK Key Exchange Algorithm ..................................7
5. Conformance Requirements ........................................8
5.1. PSK Identity Encoding ......................................8
5.2. Identity Hint ..............................................9
5.3. Requirements for TLS Implementations .......................9
5.4. Requirements for Management Interfaces .....................9
6. IANA Considerations ............................................10
7. Security Considerations ........................................10
7.1. Perfect Forward Secrecy (PFS) .............................10
7.2. Brute-Force and Dictionary Attacks ........................10
7.3. Identity Privacy ..........................................11
7.4. Implementation Notes ......................................11
8. Acknowledgements ...............................................11
9. References .....................................................12
9.1. Normative References ......................................12
9.2. Informative References ....................................12
Usually, TLS uses public key certificates [TLS] or Kerberos [KERB] for authentication. This document describes how to use symmetric keys (later called pre-shared keys or PSKs), shared in advance among the communicating parties, to establish a TLS connection.
通常、TLSは認証に公開鍵証明書[TLS]またはKerberos [KERB]を使用します。このドキュメントでは、通信相手間で事前に共有されている対称キー（後で事前共有キーまたはPSKと呼ばれます）を使用して、TLS接続を確立する方法について説明します。
There are basically two reasons why one might want to do this:
基本的に、これを実行する理由は2つあります。
o First, using pre-shared keys can, depending on the ciphersuite, avoid the need for public key operations. This is useful if TLS is used in performance-constrained environments with limited CPU power.
o まず、事前共有キーを使用すると、暗号スイートによっては、公開キー操作の必要性を回避できます。これは、CPU能力が限られている、パフォーマンスが制約された環境でTLSを使用する場合に役立ちます。
o Second, pre-shared keys may be more convenient from a key management point of view. For instance, in closed environments where the connections are mostly configured manually in advance, it may be easier to configure a PSK than to use certificates. Another case is when the parties already have a mechanism for setting up a shared secret key, and that mechanism could be used to "bootstrap" a key for authenticating a TLS connection.
o 第二に、事前共有鍵は、鍵管理の観点からはより便利な場合があります。たとえば、接続が主に事前に手動で構成されている閉じた環境では、証明書を使用するよりもPSKを構成する方が簡単な場合があります。別のケースは、当事者が共有秘密鍵をセットアップするためのメカニズムをすでに持っている場合であり、そのメカニズムは、TLS接続を認証するためのキーを「ブートストラップ」するために使用できます。
This document specifies three sets of new ciphersuites for TLS. These ciphersuites use new key exchange algorithms, and reuse existing cipher and MAC algorithms from [TLS] and [AES]. A summary of these ciphersuites is shown below.
このドキュメントでは、TLSの新しい暗号スイートの3つのセットを指定しています。これらの暗号スイートは、新しい鍵交換アルゴリズムを使用し、[TLS]および[AES]の既存の暗号およびMACアルゴリズムを再利用します。これらの暗号スイートの概要を以下に示します。
CipherSuite Key Exchange Cipher Hash
CipherSuite鍵交換暗号ハッシュ
TLS_PSK_WITH_RC4_128_SHA PSK RC4_128 SHA TLS_PSK_WITH_3DES_EDE_CBC_SHA PSK 3DES_EDE_CBC SHA TLS_PSK_WITH_AES_128_CBC_SHA PSK AES_128_CBC SHA TLS_PSK_WITH_AES_256_CBC_SHA PSK AES_256_CBC SHA TLS_DHE_PSK_WITH_RC4_128_SHA DHE_PSK RC4_128 SHA TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA DHE_PSK 3DES_EDE_CBC SHA TLS_DHE_PSK_WITH_AES_128_CBC_SHA DHE_PSK AES_128_CBC SHA TLS_DHE_PSK_WITH_AES_256_CBC_SHA DHE_PSK AES_256_CBC SHA TLS_RSA_PSK_WITH_RC4_128_SHA RSA_PSK RC4_128 SHA TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA RSA_PSK 3DES_EDE_CBC SHA TLS_RSA_PSK_WITH_AES_128_CBC_SHA RSA_PSK AES_128_CBC SHA TLS_RSA_PSK_WITH_AES_256_CBC_SHA RSA_PSK AES_256_CBC SHA
TLS_PSK_WITH_RC4_128_SHA PSK RC4_128 SHA TLS_PSK_WITH_3DES_EDE_CBC_SHA PSK 3DES_EDE_CBC SHA TLS_PSK_WITH_AES_128_CBC_SHA PSK AES_128_CBC SHA TLS_PSK_WITH_AES_256_CBC_SHA PSK AES_256_CBC SHA TLS_DHE_PSK_WITH_RC4_128_SHA DHE_PSK RC4_128 SHA TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA DHE_PSK 3DES_EDE_CBC SHA TLS_DHE_PSK_WITH_AES_128_CBC_SHA DHE_PSK AES_128_CBC SHA TLS_DHE_PSK_WITH_AES_256_CBC_SHA DHE_PSK AES_256_CBC SHA TLS_RSA_PSK_WITH_RC4_128_SHA RSA_PSK RC4_128 SHA TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA RSA_PSK 3DES_EDE_CBC SHA TLS_RSA_PSK_WITH_AES_128_CBC_SHA RSA_PSK AES_128_CBC SHA TLS_RSA_PSK_WITH_AES_256_CBC_SHA RSA_PSK AES_256_CBC SHA
The ciphersuites in Section 2 (with PSK key exchange algorithm) use only symmetric key algorithms and are thus especially suitable for performance-constrained environments.
セクション2の暗号スイート（PSKキー交換アルゴリズムを使用）は、対称キーアルゴリズムのみを使用するため、パフォーマンスが制限された環境に特に適しています。
The ciphersuites in Section 3 (with DHE_PSK key exchange algorithm) use a PSK to authenticate a Diffie-Hellman exchange. These ciphersuites protect against dictionary attacks by passive eavesdroppers (but not active attackers) and also provide Perfect Forward Secrecy (PFS).
セクション3の暗号スイート（DHE_PSK鍵交換アルゴリズムを使用）は、PSKを使用してDiffie-Hellman交換を認証します。これらの暗号スイートは、パッシブ盗聴者によるディクショナリ攻撃から保護します（アクティブな攻撃者ではありません）。また、Perfect Forward Secrecy（PFS）も提供します。
The ciphersuites in Section 4 (with RSA_PSK key exchange algorithm) combine public-key-based authentication of the server (using RSA and certificates) with mutual authentication using a PSK.
セクション4の暗号スイート（RSA_PSK鍵交換アルゴリズムを使用）は、サーバーの公開鍵ベースの認証（RSAおよび証明書を使用）とPSKを使用した相互認証を組み合わせています。
The ciphersuites defined in this document are intended for a rather limited set of applications, usually involving only a very small number of clients and servers. Even in such environments, other alternatives may be more appropriate.
このドキュメントで定義されている暗号スイートは、通常は非常に少数のクライアントとサーバーしか関与しない、かなり限定されたアプリケーションセットを対象としています。このような環境でも、他の代替手段がより適切な場合があります。
If the main goal is to avoid Public-Key Infrastructures (PKIs), another possibility worth considering is using self-signed certificates with public key fingerprints. Instead of manually configuring a shared secret in, for instance, some configuration file, a fingerprint (hash) of the other party's public key (or certificate) could be placed there instead.
主な目標が公開キー基盤（PKI）を回避することである場合、検討する価値のあるもう1つの可能性は、公開キーフィンガープリントで自己署名証明書を使用することです。たとえば、一部の構成ファイルで共有シークレットを手動で構成する代わりに、相手の公開鍵（または証明書）のフィンガープリント（ハッシュ）をそこに置くことができます。
It is also possible to use the SRP (Secure Remote Password) ciphersuites for shared secret authentication [SRP]. SRP was designed to be used with passwords, and it incorporates protection against dictionary attacks. However, it is computationally more expensive than the PSK ciphersuites in Section 2.
共有秘密認証[SRP]にSRP（Secure Remote Password）暗号スイートを使用することもできます。 SRPはパスワードで使用するように設計されており、辞書攻撃に対する保護が組み込まれています。ただし、セクション2のPSK暗号スイートよりも計算コストが高くなります。
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 [KEYWORDS].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [キーワード]で説明されているように解釈されます。
This section defines the PSK key exchange algorithm and associated ciphersuites. These ciphersuites use only symmetric key algorithms.
このセクションでは、PSK鍵交換アルゴリズムと関連する暗号スイートを定義します。これらの暗号群は、対称鍵アルゴリズムのみを使用します。
It is assumed that the reader is familiar with the ordinary TLS handshake, shown below. The elements in parenthesis are not included when the PSK key exchange algorithm is used, and "*" indicates a situation-dependent message that is not always sent.
以下に示すように、読者は通常のTLSハンドシェイクに精通していることを前提としています。 PSK鍵交換アルゴリズムが使用される場合、括弧内のエレメントは含まれません。「*」は、常に送信されるわけではない状況依存のメッセージを示します。
Client Server
------ ------
ClientHello -------->
ServerHello
(Certificate)
ServerKeyExchange*
(CertificateRequest)
<-------- ServerHelloDone
(Certificate)
ClientKeyExchange
(CertificateVerify)
ChangeCipherSpec
Finished -------->
ChangeCipherSpec
<-------- Finished
Application Data <-------> Application Data
The client indicates its willingness to use pre-shared key authentication by including one or more PSK ciphersuites in the ClientHello message. If the TLS server also wants to use pre-shared keys, it selects one of the PSK ciphersuites, places the selected ciphersuite in the ServerHello message, and includes an appropriate ServerKeyExchange message (see below). The Certificate and CertificateRequest payloads are omitted from the response.
クライアントは、ClientHelloメッセージに1つ以上のPSK暗号スイートを含めることにより、事前共有キー認証を使用する意思を示します。 TLSサーバーも事前共有キーを使用する場合は、PSK暗号スイートの1つを選択し、選択した暗号スイートをServerHelloメッセージに配置し、適切なServerKeyExchangeメッセージを含めます（以下を参照）。 CertificateおよびCertificateRequestペイロードは、応答から省略されます。
Both clients and servers may have pre-shared keys with several different parties. The client indicates which key to use by including a "PSK identity" in the ClientKeyExchange message (note that unlike in [SHAREDKEYS], the session_id field in ClientHello message keeps its usual meaning). To help the client in selecting which identity to use, the server can provide a "PSK identity hint" in the ServerKeyExchange message. If no hint is provided, the ServerKeyExchange message is omitted. See Section 5 for a more detailed description of these fields.
クライアントとサーバーの両方が、いくつかの異なる関係者と事前共有キーを持っている場合があります。クライアントは、ClientKeyExchangeメッセージに「PSK ID」を含めることで、使用するキーを示します（[SHAREDKEYS]とは異なり、ClientHelloメッセージのsession_idフィールドは通常の意味を維持することに注意してください）。クライアントが使用するIDを選択するのを助けるために、サーバーはServerKeyExchangeメッセージで「PSK IDヒント」を提供できます。ヒントが提供されない場合、ServerKeyExchangeメッセージは省略されます。これらのフィールドの詳細については、セクション5を参照してください。
The format of the ServerKeyExchange and ClientKeyExchange messages is shown below.
ServerKeyExchangeおよびClientKeyExchangeメッセージの形式を以下に示します。
struct {
select (KeyExchangeAlgorithm) {
/* other cases for rsa, diffie_hellman, etc. */
case psk: /* NEW */
opaque psk_identity_hint<0..2^16-1>;
};
} ServerKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
/* other cases for rsa, diffie_hellman, etc. */
case psk: /* NEW */
opaque psk_identity<0..2^16-1>;
} exchange_keys;
} ClientKeyExchange;
The premaster secret is formed as follows: if the PSK is N octets long, concatenate a uint16 with the value N, N zero octets, a second uint16 with the value N, and the PSK itself.
プリマスターシークレットは次のように形成されます。PSKがNオクテット長の場合、uint16を値N、Nゼロオクテット、2番目のuint16を値N、およびPSK自体と連結します。
Note 1: All the ciphersuites in this document share the same general structure for the premaster secret, namely,
注1：このドキュメントのすべての暗号スイートは、プレマスターシークレットと同じ一般的な構造を共有しています。
struct {
opaque other_secret<0..2^16-1>;
opaque psk<0..2^16-1>;
};
Here "other_secret" either is zeroes (plain PSK case) or comes from the Diffie-Hellman or RSA exchange (DHE_PSK and RSA_PSK, respectively). See Sections 3 and 4 for a more detailed description.
ここで、「other_secret」はゼロ（プレーンなPSKの場合）か、Diffie-HellmanまたはRSA交換（それぞれDHE_PSKおよびRSA_PSK）に由来します。詳細については、セクション3および4を参照してください。
Note 2: Using zeroes for "other_secret" effectively means that only the HMAC-SHA1 part (but not the HMAC-MD5 part) of the TLS PRF is used when constructing the master secret. This was considered more elegant from an analytical viewpoint than, for instance, using the same key for both the HMAC-MD5 and HMAC-SHA1 parts. See [KRAWCZYK] for a more detailed rationale.
注2：「other_secret」にゼロを使用すると、マスターシークレットを作成するときに、TLS PRFのHMAC-SHA1部分のみが使用されます（HMAC-MD5部分は使用されません）。これは、たとえば、HMAC-MD5とHMAC-SHA1の両方のパーツに同じキーを使用するよりも、分析の観点からはエレガントであると考えられていました。根拠の詳細については、[KRAWCZYK]を参照してください。
The TLS handshake is authenticated using the Finished messages as usual.
TLSハンドシェイクは、通常どおりFinishedメッセージを使用して認証されます。
If the server does not recognize the PSK identity, it MAY respond with an "unknown_psk_identity" alert message. Alternatively, if the server wishes to hide the fact that the PSK identity was not known, it MAY continue the protocol as if the PSK identity existed but the key was incorrect: that is, respond with a "decrypt_error" alert.
サーバーがPSK IDを認識しない場合、「unknown_psk_identity」アラートメッセージで応答する場合があります。あるいは、サーバーがPSK IDが不明であるという事実を隠したい場合は、PSK IDが存在するがキーが正しくない場合と同様にプロトコルを続行できます。つまり、「decrypt_error」アラートで応答します。
This section defines additional ciphersuites that use a PSK to authenticate a Diffie-Hellman exchange. These ciphersuites give some additional protection against dictionary attacks and also provide Perfect Forward Secrecy (PFS). See Section 7 for discussion of related security considerations.
このセクションでは、PSKを使用してDiffie-Hellman交換を認証する追加の暗号スイートを定義します。これらの暗号群は、辞書攻撃に対する追加の保護を提供し、Perfect Forward Secrecy（PFS）も提供します。関連するセキュリティの考慮事項については、セクション7を参照してください。
When these ciphersuites are used, the ServerKeyExchange and ClientKeyExchange messages also include the Diffie-Hellman parameters. The PSK identity and identity hint fields have the same meaning as in the previous section (note that the ServerKeyExchange message is always sent, even if no PSK identity hint is provided).
これらの暗号スイートを使用すると、ServerKeyExchangeおよびClientKeyExchangeメッセージにもDiffie-Hellmanパラメータが含まれます。 PSK IDおよびIDヒントフィールドは、前のセクションと同じ意味を持ちます（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 diffie_hellman_psk: /* NEW */
opaque psk_identity_hint<0..2^16-1>;
ServerDHParams params;
};
} ServerKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
/* other cases for rsa, diffie_hellman, etc. */
case diffie_hellman_psk: /* NEW */
opaque psk_identity<0..2^16-1>;
ClientDiffieHellmanPublic public;
} exchange_keys;
} ClientKeyExchange;
The premaster secret is formed as follows. First, perform the Diffie-Hellman computation in the same way as for other Diffie-Hellman-based ciphersuites in [TLS]. Let Z be the value produced by this computation (with leading zero bytes stripped as in other Diffie-Hellman-based ciphersuites). 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.
プリマスターシークレットは次のように形成されます。最初に、[TLS]の他のDiffie-Hellmanベースの暗号スイートと同じ方法でDiffie-Hellman計算を実行します。この計算によって生成された値をZとします（他のDiffie-Hellmanベースの暗号スイートと同様に、先頭の0バイトが削除されます）。 Z（オクテット単位）の長さを含むuint16、Z自体、PSK（オクテット単位）の長さを含むuint16、およびPSK自体を連結します。
This corresponds to the general structure for the premaster secrets (see Note 1 in Section 2) in this document, with "other_secret" containing Z.
これは、このドキュメントのプリマスターシークレット（セクション2の注1を参照）の一般的な構造に対応し、「other_secret」にはZが含まれています。
The ciphersuites in this section use RSA and certificates to authenticate the server, in addition to using a PSK.
このセクションの暗号スイートは、PSKの使用に加えて、RSAと証明書を使用してサーバーを認証します。
As in normal RSA ciphersuites, the server must send a Certificate message. The format of the ServerKeyExchange and ClientKeyExchange messages is shown below. If no PSK identity hint is provided, the ServerKeyExchange message is omitted.
通常のRSA暗号スイートと同様に、サーバーは証明書メッセージを送信する必要があります。 ServerKeyExchangeおよびClientKeyExchangeメッセージの形式を以下に示します。 PSK IDヒントが提供されない場合、ServerKeyExchangeメッセージは省略されます。
struct {
select (KeyExchangeAlgorithm) {
/* other cases for rsa, diffie_hellman, etc. */
case rsa_psk: /* NEW */
opaque psk_identity_hint<0..2^16-1>;
};
} ServerKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
/* other cases for rsa, diffie_hellman, etc. */
case rsa_psk: /* NEW */
opaque psk_identity<0..2^16-1>;
EncryptedPreMasterSecret;
} exchange_keys;
} ClientKeyExchange;
The EncryptedPreMasterSecret field sent from the client to the server contains a 2-byte version number and a 46-byte random value, encrypted using the server's RSA public key as described in Section 7.4.7.1 of [TLS]. The actual premaster secret is formed by both parties as follows: concatenate a uint16 with the value 48, the 2-byte version number and the 46-byte random value, a uint16 containing the length of the PSK (in octets), and the PSK itself. (The premaster secret is thus 52 octets longer than the PSK.) This corresponds to the general structure for the premaster secrets (see Note 1 in Section 2) in this document, with "other_secret" containing both the 2-byte version number and the 46-byte random value.
クライアントからサーバーに送信されるEncryptedPreMasterSecretフィールドには、2バイトのバージョン番号と46バイトのランダムな値が含まれ、[TLS]のセクション7.4.7.1で説明されているようにサーバーのRSA公開鍵を使用して暗号化されます。実際のプリマスターシークレットは、次のように両方の当事者によって形成されます。uint16を値48、2バイトのバージョン番号と46バイトのランダム値、PSKの長さ（オクテット単位）を含むuint16、およびPSKと連結します。自体。 （したがって、プリマスターシークレットはPSKよりも52オクテット長くなります。）これは、このドキュメントのプリマスターシークレット（セクション2の注1を参照）の一般的な構造に対応し、「other_secret」には2バイトのバージョン番号と46バイトのランダムな値。
Neither the normal RSA ciphersuites nor these RSA_PSK ciphersuites themselves specify what the certificates contain (in addition to the RSA public key), or how the certificates are to be validated. In particular, it is possible to use the RSA_PSK ciphersuites with unvalidated self-signed certificates to provide somewhat similar protection against dictionary attacks, as the DHE_PSK ciphersuites define in Section 3.
通常のRSA暗号スイートもこれらのRSA_PSK暗号スイート自体も、証明書に含まれるもの（RSA公開鍵に加えて）、または証明書の検証方法を指定しません。特に、セクション3で定義されているDHE_PSK暗号スイートと同様に、RSA_PSK暗号スイートを未検証の自己署名証明書と共に使用して、辞書攻撃に対してある程度類似した保護を提供することが可能です。
It is expected that different types of identities are useful for different applications running over TLS. This document does not therefore mandate the use of any particular type of identity (such as IPv4 address or Fully Qualified Domain Name (FQDN)).
TLSを介して実行されるさまざまなアプリケーションには、さまざまなタイプのIDが役立つと予想されます。したがって、このドキュメントでは、特定の種類のID（IPv4アドレスや完全修飾ドメイン名（FQDN）など）の使用を義務付けていません。
However, the TLS client and server clearly have to agree on the identities and keys to be used. To improve interoperability, this document places requirements on how the identity is encoded in the protocol, and what kinds of identities and keys implementations have to support.
ただし、TLSクライアントとサーバーは、使用するIDとキーについて明確に合意する必要があります。相互運用性を向上させるために、このドキュメントでは、プロトコルでIDをエンコードする方法、および実装でサポートする必要があるIDとキーの種類について要件を定めています。
The requirements for implementations are divided into two categories, requirements for TLS implementations and management interfaces. In this context, "TLS implementation" refers to a TLS library or module that is intended to be used for several different purposes, while "management interface" would typically be implemented by a particular application that uses TLS.
実装の要件は、TLS実装の要件と管理インターフェースの2つのカテゴリに分類されます。このコンテキストでは、「TLS実装」はいくつかの異なる目的で使用することを目的としたTLSライブラリまたはモジュールを指しますが、「管理インターフェース」は通常、TLSを使用する特定のアプリケーションによって実装されます。
This document does not specify how the server stores the keys and identities, or how exactly it finds the key corresponding to the identity it receives. For instance, if the identity is a domain name, it might be appropriate to do a case-insensitive lookup. It is RECOMMENDED that before looking up the key, the server processes the PSK identity with a stringprep profile [STRINGPREP] appropriate for the identity in question (such as Nameprep [NAMEPREP] for components of domain names or SASLprep for usernames [SASLPREP]).
このドキュメントでは、サーバーがキーとIDを保存する方法、またはサーバーが受け取るIDに対応するキーをサーバーがどのように正確に見つけるかについては指定していません。たとえば、IDがドメイン名の場合、大文字と小文字を区別しない検索を行うのが適切な場合があります。サーバーは、キーを検索する前に、問題のIDに適切なstringprepプロファイル[STRINGPREP]（ドメイン名のコンポーネントのNameprep [NAMEPREP]またはユーザー名のSASLprep [SASLPREP]など）でPSK IDを処理することをお勧めします。
The PSK identity MUST be first converted to a character string, and then encoded to octets using UTF-8 [UTF8]. For instance,
PSK IDは、最初に文字列に変換されてから、UTF-8 [UTF8]を使用してオクテットにエンコードされる必要があります。例えば、
o IPv4 addresses are sent as dotted-decimal strings (e.g., "192.0.2.1"), not as 32-bit integers in network byte order.
o IPv4アドレスは、ネットワークバイトオーダーの32ビット整数としてではなく、ドット付き10進文字列（「192.0.2.1」など）として送信されます。
o Domain names are sent in their usual text form [DNS] (e.g., "www.example.com" or "embedded\.dot.example.net"), not in DNS protocol format.
o ドメイン名は、DNSプロトコル形式ではなく、通常のテキスト形式[DNS]（「www.example.com」や「embedded \ .dot.example.net」など）で送信されます。
o X.500 Distinguished Names are sent in their string representation [LDAPDN], not as BER-encoded ASN.1.
o X.500識別名は、BERエンコードされたASN.1ではなく、文字列表現[LDAPDN]で送信されます。
This encoding is clearly not optimal for many types of identities. It was chosen to avoid identity-type-specific parsing and encoding code in implementations where the identity is configured by a person using some kind of management interface. Requiring such identity-type-specific code would also increase the chances for interoperability problems resulting from different implementations supporting different identity types.
このエンコーディングは、多くの種類のIDには明らかに最適ではありません。これは、ある種類の管理インターフェイスを使用してユーザーがIDを構成する実装で、IDタイプ固有の解析およびエンコードコードを回避するために選択されました。このようなIDタイプ固有のコードが必要になると、さまざまなIDタイプをサポートするさまざまな実装に起因する相互運用性の問題が発生する可能性も高くなります。
In the absence of an application profile specification specifying otherwise, servers SHOULD NOT provide an identity hint and clients MUST ignore the identity hint field. Applications that do use this field MUST specify its contents, how the value is chosen by the TLS server, and what the TLS client is expected to do with the value.
特に指定しないアプリケーションプロファイル仕様がない場合、サーバーはIDヒントを提供してはならず（SHOULD NOT）、クライアントはIDヒントフィールドを無視する必要があります（MUST）。このフィールドを使用するアプリケーションは、その内容、TLSサーバーによる値の選択方法、およびTLSクライアントがその値で何を行うことが期待されるかを指定する必要があります。
TLS implementations supporting these ciphersuites MUST support arbitrary PSK identities up to 128 octets in length, and arbitrary PSKs up to 64 octets in length. Supporting longer identities and keys is RECOMMENDED.
これらの暗号スイートをサポートするTLS実装は、長さが最大128オクテットの任意のPSK ID、および長さが最大64オクテットの任意のPSKをサポートする必要があります。より長いIDとキーをサポートすることをお勧めします。
In the absence of an application profile specification specifying otherwise, a management interface for entering the PSK and/or PSK identity MUST support the following:
特に指定しないアプリケーションプロファイル仕様がない場合、PSKおよび/またはPSK IDを入力するための管理インターフェイスは、以下をサポートする必要があります。
o Entering PSK identities consisting of up to 128 printable Unicode characters. Supporting as wide a character repertoire and as long identities as feasible is RECOMMENDED.
o 最大128の印刷可能なUnicode文字で構成されるPSK IDを入力します。キャラクターの幅広いレパートリーと、可能な限り長いアイデンティティをサポートすることをお勧めします。
o Entering PSKs up to 64 octets in length as ASCII strings and in hexadecimal encoding.
o 長さが最大64オクテットのPSKをASCII文字列として、16進エンコードで入力します。
IANA does not currently have a registry for TLS ciphersuite or alert numbers, so there are no IANA actions associated with this document.
IANAには現在TLS暗号スイートまたはアラート番号のレジストリがないため、このドキュメントに関連付けられているIANAアクションはありません。
For easier reference in the future, the ciphersuite numbers defined in this document are summarized below.
将来の参照を容易にするために、このドキュメントで定義されている暗号スイート番号を以下にまとめます。
CipherSuite TLS_PSK_WITH_RC4_128_SHA = { 0x00, 0x8A };
CipherSuite TLS_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x8B };
CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0x8C };
CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0x8D };
CipherSuite TLS_DHE_PSK_WITH_RC4_128_SHA = { 0x00, 0x8E };
CipherSuite TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x8F };
CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0x90 };
CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0x91 };
CipherSuite TLS_RSA_PSK_WITH_RC4_128_SHA = { 0x00, 0x92 };
CipherSuite TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x93 };
CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0x94 };
CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0x95 };
This document also defines a new TLS alert message, unknown_psk_identity(115).
このドキュメントでは、新しいTLSアラートメッセージ、unknown_psk_identity（115）も定義しています。
As with all schemes involving shared keys, special care should be taken to protect the shared values and to limit their exposure over time.
共有キーを含むすべてのスキームと同様に、共有値を保護し、時間の経過に伴うそれらの公開を制限するように特別な注意を払う必要があります。
The PSK and RSA_PSK ciphersuites defined in this document do not provide Perfect Forward Secrecy (PFS). That is, if the shared secret key (in PSK ciphersuites), or both the shared secret key and the RSA private key (in RSA_PSK ciphersuites), is somehow compromised, an attacker can decrypt old conversations.
このドキュメントで定義されているPSKおよびRSA_PSK暗号スイートは、Perfect Forward Secrecy（PFS）を提供しません。つまり、共有秘密鍵（PSK暗号群）、または共有秘密鍵とRSA秘密鍵（RSA_PSK暗号群）の両方が何らかの形で侵害された場合、攻撃者は古い会話を解読できます。
The DHE_PSK ciphersuites provide Perfect Forward Secrecy if a fresh Diffie-Hellman private key is generated for each handshake.
DHE_PSK暗号スイートは、ハンドシェイクごとに新しいDiffie-Hellman秘密鍵が生成される場合、Perfect Forward Secrecyを提供します。
Use of a fixed shared secret of limited entropy (for example, a PSK that is relatively short, or was chosen by a human and thus may contain less entropy than its length would imply) may allow an attacker to perform a brute-force or dictionary attack to recover the secret. This may be either an off-line attack (against a captured TLS handshake messages) or an on-line attack where the attacker attempts to connect to the server and tries different keys.
制限されたエントロピーの固定共有シークレットを使用すると（たとえば、PSKが比較的短いか、人間が選択したため、長さが示すよりもエントロピーが少ない可能性がある）、攻撃者がブルートフォースや辞書を実行できる可能性があります秘密を取り戻すために攻撃します。これは、オフラインの攻撃（キャプチャされたTLSハンドシェイクメッセージに対する）か、攻撃者がサーバーに接続しようとして別のキーを試すオンライン攻撃のいずれかです。
For the PSK ciphersuites, an attacker can get the information required for an off-line attack by eavesdropping on a TLS handshake, or by getting a valid client to attempt connection with the attacker (by tricking the client to connect to the wrong address, or by intercepting a connection attempt to the correct address, for instance).
PSK暗号スイートの場合、攻撃者はTLSハンドシェイクを盗聴することにより、または有効なクライアントに攻撃者との接続を試行させることにより（クライアントをだまして間違ったアドレスに接続させることにより）、オフライン攻撃に必要な情報を取得できます。たとえば、正しいアドレスへの接続試行を代行受信するなど）。
For the DHE_PSK ciphersuites, an attacker can obtain the information by getting a valid client to attempt connection with the attacker. Passive eavesdropping alone is not sufficient.
DHE_PSK暗号スイートの場合、有効なクライアントに攻撃者との接続を試行させることにより、攻撃者は情報を入手できます。パッシブ盗聴だけでは十分ではありません。
For the RSA_PSK ciphersuites, only the server (authenticated using RSA and certificates) can obtain sufficient information for an off-line attack.
RSA_PSK暗号スイートの場合、サーバー（RSAおよび証明書を使用して認証されたもの）のみがオフライン攻撃に関する十分な情報を取得できます。
It is RECOMMENDED that implementations that allow the administrator to manually configure the PSK also provide a functionality for generating a new random PSK, taking [RANDOMNESS] into account.
管理者がPSKを手動で構成できる実装は、[ランダム]を考慮して新しいランダムPSKを生成する機能も提供することをお勧めします。
The PSK identity is sent in cleartext. Although using a user name or other similar string as the PSK identity is the most straightforward option, it may lead to problems in some environments since an eavesdropper is able to identify the communicating parties. Even when the identity does not reveal any information itself, reusing the same identity over time may eventually allow an attacker to perform traffic analysis to identify the parties. It should be noted that this is no worse than client certificates, since they are also sent in cleartext.
PSK IDはクリアテキストで送信されます。 PSK IDとしてユーザー名または他の同様の文字列を使用するのが最も簡単なオプションですが、盗聴者が通信相手を識別できるため、環境によっては問題が発生する可能性があります。 ID自体が情報を明らかにしない場合でも、時間の経過とともに同じIDを再利用すると、攻撃者がトラフィック分析を実行して関係者を特定できる可能性があります。クリアテキストでも送信されるため、これはクライアント証明書よりも悪くないことに注意してください。
The implementation notes in [TLS11] about correct implementation and use of RSA (including Section 7.4.7.1) and Diffie-Hellman (including Appendix F.1.1.3) apply to the DHE_PSK and RSA_PSK ciphersuites as well.
RSA（セクション7.4.7.1を含む）とDiffie-Hellman（付録F.1.1.3を含む）の正しい実装と使用に関する[TLS11]の実装メモは、DHE_PSKおよびRSA_PSK暗号スイートにも適用されます。
The protocol defined in this document is heavily based on work by Tim Dierks and Peter Gutmann, and borrows some text from [SHAREDKEYS] and [AES]. The DHE_PSK and RSA_PSK ciphersuites are based on earlier work in [KEYEX].
このドキュメントで定義されているプロトコルは、Tim DierksとPeter Gutmannによる作業に大きく基づいており、[SHAREDKEYS]と[AES]からテキストを借用しています。 DHE_PSKおよびRSA_PSK暗号スイートは、[KEYEX]での以前の作業に基づいています。
Valuable feedback was also provided by Bernard Aboba, Lakshminath Dondeti, Philip Ginzboorg, Peter Gutmann, Sam Hartman, Russ Housley, David Jablon, Nikos Mavroyanopoulos, Bodo Moeller, Eric Rescorla, and Mika Tervonen.
貴重なフィードバックは、Bernard Aboba、Lakshminath Dondeti、Philip Ginzboorg、Peter Gutmann、Sam Hartman、Russ Housley、David Jablon、Nikos Mavroyanopoulos、Bodo Moeller、Eric Rescorla、およびMika Tervonenからも提供されました。
When the first version of this document was almost ready, the authors learned that something similar had been proposed already in 1996 [PASSAUTH]. However, this document is not intended for web password authentication, but rather for other uses of TLS.
このドキュメントの最初のバージョンがほぼ準備ができたとき、著者は同様のものがすでに1996年に提案されていることを知りました[PASSAUTH]。ただし、このドキュメントはWebパスワード認証を目的としたものではなく、TLSの他の用途を対象としています。
[AES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
[AES] Chown、P。、「Advanced Encryption Standard（AES）Ciphersuites for Transport Layer Security（TLS）」、RFC 3268、2002年6月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RANDOMNESS] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[ランダム] Eastlake、D.、3rd、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS] Dierks、T。およびC. Allen、「The TLS Protocol Version 1.0」、RFC 2246、1999年1月。
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF8] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[DNS] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
[KERB] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", RFC 2712, October 1999.
[KERB] Medvinsky、A.およびM. Hur、「Additioning Kerberos Cipher Suites to Transport Layer Security（TLS）」、RFC 2712、1999年10月。
[KEYEX] Badra, M., Cherkaoui, O., Hajjeh, I. and A. Serhrouchni, "Pre-Shared-Key key Exchange methods for TLS", Work in Progress, August 2004.
[KEYEX] Badra、M.、Cherkaoui、O.、Hajjeh、I。およびA. Serhrouchni、「TLSの事前共有鍵の鍵交換方法」、作業中、2004年8月。
[KRAWCZYK] Krawczyk, H., "Re: TLS shared keys PRF", message on ietf-tls@lists.certicom.com mailing list 2004-01-13, http://www.imc.org/ietf-tls/mail-archive/msg04098.html.
[KRAWCZYK] Krawczyk、H。、「Re：TLS共有キーPRF」、ietf-tls @ lists.certicom.comメーリングリスト2004-01-13、http：//www.imc.org/ietf-tls/のメッセージmail-archive / msg04098.html。
[LDAPDN] Zeilenga, K., "LDAP: String Representation of Distinguished Names", Work in Progress, February 2005.
[LDAPDN] Zeilenga、K。、「LDAP：String Representation of Distinguished Names」、Work in Progress、2005年2月。
[NAMEPREP] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
[NAMEPREP]ホフマン、P.、M。ブランシェ、「Nameprep：国際化ドメイン名（IDN）のStringprepプロファイル」、RFC 3491、2003年3月。
[PASSAUTH] Simon, D., "Addition of Shared Key Authentication to Transport Layer Security (TLS)", Work in Progress, November 1996.
[PASSAUTH] Simon、D。、「トランスポート層セキュリティ（TLS）への共有キー認証の追加」、作業中、1996年11月。
[SASLPREP] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[SASLPREP] Zeilenga、K。、「SASLprep：Stringprep Profile for User Names and Passwords」、RFC 4013、2005年2月。
[SHAREDKEYS] Gutmann, P., "Use of Shared Keys in the TLS Protocol", Work in Progress, October 2003.
[SHAREDKEYS] Gutmann、P。、「TLSプロトコルでの共有キーの使用」、進行中の作業、2003年10月。
[SRP] Taylor, D., Wu, T., Mavroyanopoulos, N. and T. Perrin, "Using SRP for TLS Authentication", Work in Progress, March 2005.
[SRP] Taylor、D.、Wu、T.、Mavroyanopoulos、N。およびT. Perrin、「Using SRP for TLS Authentication」、Work in Progress、2005年3月。
[STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[STRINGPREP]ホフマン、P。およびM.ブランシェ、「Preparation of Internationalized Strings（ "stringprep"）」、RFC 3454、2002年12月。
[TLS11] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", Work in Progress, June 2005.
[TLS11] Dierks、T。およびE. Rescorla、「The TLS Protocol Version 1.1」、Work in Progress、2005年6月。
Authors' and Contributors' Addresses
著者と寄稿者のアドレス
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland
Pasi EronenノキアリサーチセンターP.O.ボックス407 FIN-00045ノキアグループフィンランド
EMail: pasi.eronen@nokia.com
Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany
Hannes Tschofenig Siemens Otto-Hahn-Ring 6ミュンヘンバイエルン州ドイツ
EMail: Hannes.Tschofenig@siemens.com Mohamad Badra ENST Paris 46 rue Barrault 75634 Paris France
メール：Hannes.Tschofenig@siemens.com Mohamad Badra ENST Paris 46 rue Barrault 75634 Paris France
EMail: Mohamad.Badra@enst.fr
Omar Cherkaoui UQAM University Montreal (Quebec) Canada
Omar Cherkaoui UQAM Universityモントリオール（ケベック）カナダ
EMail: cherkaoui.omar@uqam.ca
Ibrahim Hajjeh ESRGroups 17 passage Barrault 75013 Paris France
イブラヒムハイジェESRGroups 17継目バロー75013パリフランス
EMail: Ibrahim.Hajjeh@esrgroups.org
Ahmed Serhrouchni ENST Paris 46 rue Barrault 75634 Paris France
Ahmed Serhrouchni ENST Paris 46 rue Barrault 75634 Paris Paris France
EMail: Ahmed.Serhrouchni@enst.fr
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
Copyright（C）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または組織（ある場合）、インターネットエンジニアリングおよびインターネットエンジニアリングタスクフォースは、すべての保証を明示的または明示的に後援します。ここに含まれる情報の使用により、商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害されないという保証を含みますが、これに限定されるものではありません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われたIPR開示のコピー、および使用可能にされるライセンスの保証、または一般ライセンスを取得する試みの結果、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得できるhttp://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。