[要約] RFC 4785は、Transport Layer Security (TLS) プロトコルにおいて、NULL暗号化を使用するPre-Shared Key (PSK) Ciphersuitesに関するものです。この文書の目的は、データの暗号化を行わずに、認証とデータの完全性保護のみを提供するTLSの使用シナリオをサポートすることにあります。このような利用場面は、帯域幅が限られている環境や、データの機密性を保護する必要がないが、データの改ざん防止は必要な場合に適しています。関連するRFCには、TLSの基本を定義するRFC 5246(TLS 1.2)や、PSK認証を扱うRFC 4279があります。
Network Working Group U. Blumenthal Request for Comments: 4785 P. Goel Category: Standards Track Intel Corporation January 2007
Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS)
トランスポート層セキュリティ(TLS)のNULL暗号化を使用した事前共有キー(PSK)暗号スイート
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 IETF Trust (2007).
Copyright(C)IETF Trust(2007)。
Abstract
概要
This document specifies authentication-only ciphersuites (with no encryption) for the Pre-Shared Key (PSK) based Transport Layer Security (TLS) protocol. These ciphersuites are useful when authentication and integrity protection is desired, but confidentiality is not needed or not permitted.
このドキュメントでは、事前共有キー(PSK)ベースのトランスポート層セキュリティ(TLS)プロトコルの認証のみの暗号スイート(暗号化なし)を指定します。これらの暗号スイートは、認証と整合性保護が必要な場合に役立ちますが、機密性は必要ないか、許可されません。
Table of Contents
目次
1. Introduction ....................................................2 1.1. Applicability Statement ....................................2 2. Conventions Used in This Document ...............................2 3. Cipher Usage ....................................................3 4. Security Considerations .........................................3 5. IANA Considerations .............................................3 6. Acknowledgments .................................................3 7. References ......................................................4 7.1. Normative References .......................................4 7.2. Informative References .....................................4
The RFC for Pre-Shared Key (PSK) based Transport Layer Security (TLS) [TLS-PSK] specifies ciphersuites for supporting TLS using pre-shared symmetric keys. However, all the ciphersuites defined in [TLS-PSK] require encryption. However there are cases when only authentication and integrity protection is required, and confidentiality is not needed. There are also cases when confidentiality is not permitted - e.g., for implementations that must meet import restrictions in some countries. Even though no encryption is used, these ciphersuites support authentication of the client and server to each other, and message integrity. This document augments [TLS-PSK] by adding three more ciphersuites (PSK, DHE_PSK, RSA_PSK) with authentication and integrity only - no encryption. The reader is expected to become familiar with [TLS-PSK] standards prior to studying this document.
事前共有キー(PSK)ベースのトランスポート層セキュリティ(TLS)のRFC [TLS-PSK]は、事前共有対称キーを使用してTLSをサポートするための暗号スイートを指定します。ただし、[TLS-PSK]で定義されているすべての暗号スイートには暗号化が必要です。ただし、認証と整合性保護のみが必要で、機密性は不要な場合があります。一部の国では輸入制限を満たさなければならない実装など、機密性が許可されない場合もあります。暗号化は使用されていませんが、これらの暗号スイートは、クライアントとサーバーの相互認証とメッセージの整合性をサポートしています。このドキュメントは、認証と整合性のみ-暗号化なし-で3つの暗号スイート(PSK、DHE_PSK、RSA_PSK)を追加することにより、[TLS-PSK]を補強します。読者は、このドキュメントを読む前に、[TLS-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 Secure Remote Password (SRP) 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 [TLS-PSK].
共有秘密認証[SRP]にSecure Remote Password(SRP)暗号スイートを使用することもできます。 SRPはパスワードで使用するように設計されており、辞書攻撃に対する保護が組み込まれています。ただし、[TLS-PSK]の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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The three new ciphersuites proposed here match the three cipher suites defined in [TLS-PSK], except that we define suites with null encryption.
ここで提案されている3つの新しい暗号スイートは、[TLS-PSK]で定義されている3つの暗号スイートと一致しています。ただし、スイートがnull暗号化で定義されている点が異なります。
The ciphersuites defined here use the following options for key exchange and hash part of the protocol:
ここで定義されている暗号群は、プロトコルのキー交換とハッシュ部分に次のオプションを使用します。
CipherSuite Key Exchange Cipher Hash
CipherSuite鍵交換暗号ハッシュ
TLS_PSK_WITH_NULL_SHA PSK NULL SHA TLS_DHE_PSK_WITH_NULL_SHA DHE_PSK NULL SHA TLS_RSA_PSK_WITH_NULL_SHA RSA_PSK NULL SHA
TLS_PSK_WITH_NULL_SHA PSK NULL SHA TLS_DHE_PSK_WITH_NULL_SHA DHE_PSK NULL SHA TLS_RSA_PSK_WITH_NULL_SHA RSA_PSK NULL SHA
For the meaning of the terms PSK, please refer to section 1 in [TLS-PSK]. For the meaning of the terms DHE, RSA, and SHA, please refer to appendixes A.5 and B in [TLS].
PSKという用語の意味については、[TLS-PSK]のセクション1を参照してください。 DHE、RSA、およびSHAという用語の意味については、[TLS]の付録A.5およびBを参照してください。
As with all schemes involving shared keys, special care should be taken to protect the shared values and to limit their exposure over time. As this document augments [TLS-PSK], everything stated in its Security Consideration section applies here. In addition, as cipher suites 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 ciphersuites defined in this document.
共有キーを含むすべてのスキームと同様に、共有値を保護し、時間の経過に伴うそれらの公開を制限するように特別な注意を払う必要があります。このドキュメントは[TLS-PSK]を補足するものであるため、「セキュリティに関する考慮事項」セクションで述べたすべてがここに適用されます。さらに、ここで定義されている暗号スイートは機密性をサポートしていないため、このドキュメントで定義されている暗号スイートの1つで保護された接続を介して機密情報(パスワードなど)を送信しないように注意する必要があります。
This document defines three new ciphersuites whose values are in the TLS Cipher Suite registry defined in [TLS].
このドキュメントは、値が[TLS]で定義されたTLS Cipher Suiteレジストリにある3つの新しい暗号スイートを定義します。
CipherSuite TLS_PSK_WITH_NULL_SHA = { 0x00, 0x2C }; CipherSuite TLS_DHE_PSK_WITH_NULL_SHA = { 0x00, 0x2D }; CipherSuite TLS_RSA_PSK_WITH_NULL_SHA = { 0x00, 0x2E };
The ciphersuites defined in this document are an augmentation to and based on [TLS-PSK].
このドキュメントで定義されている暗号スイートは、[TLS-PSK]を拡張したものです。
[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月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[TLS] Dierks、T。およびE. Rescorla、「The Transport Layer Security(TLS)Protocol Version 1.1」、RFC 4346、2006年4月。
[TLS-PSK] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.
[TLS-PSK] Eronen、P。およびH. Tschofenig、「トランスポート層セキュリティ(TLS)の事前共有鍵暗号スイート」、RFC 4279、2005年12月。
[SRP] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, "Using SRP for TLS Authentication", Work in Progress, December 2006.
[SRP] Taylor、D.、Wu、T.、Mavrogiannopoulos、N。、およびT. Perrin、「TLS認証でのSRPの使用」、進行中の作業、2006年12月。
Authors' Addresses
著者のアドレス
Uri Blumenthal Intel Corporation 1515 State Route 10, PY2-1 10-4 Parsippany, NJ 07054 USA
Uri Blumenthal Intel Corporation 1515 State Route 10、PY2-1 10-4 Parsippany、NJ 07054 USA
EMail: urimobile@optonline.net
Purushottam Goel Intel Corporation 2111 N.E. 25 Ave. JF3-414 Hillsboro, OR 97124 USA
プルショタムゴエルインテルコーポレーション2111 N.E. 25 Ave. JF3-414 Hillsboro、OR 97124 USA
EMail: Purushottam.Goel@intel.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The IETF Trust (2007).
Copyright(C)IETF Trust(2007)。
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, THE IETF TRUST 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.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または(もしあれば)組織、インターネット社会、IETFトラスト、およびインターネットエンジニアリングタスクフォースはすべてを否認します。明示または黙示を問わず、ここに含まれる情報の使用が商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害しないことを保証するものではありません。
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から提供されています。