RFC 3853 - S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3853
タイトル : RFC 3853 - S/MIME Advanced暗号化標準（AES）セッション開始プロトコル（SIP）の要件
翻訳編集 : 自動生成

[要約] RFC 3853は、SIPにおけるS/MIME Advanced Encryption Standard (AES)の要件を定義しています。目的は、SIPセッションの暗号化にAESを使用するためのガイドラインを提供することです。

Network Working Group                                        J. Peterson
Request for Comments: 3853                                       Neustar
Updates: 3261                                                  July 2004
Category: Standards Track

S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)

S/MIME Advanced暗号化標準（AES）セッション開始プロトコル（SIP）の要件

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）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

著作権（c）The Internet Society（2004）。

Abstract

概要

RFC 3261 currently specifies 3DES as the mandatory-to-implement ciphersuite for implementations of S/MIME in the Session Initiation Protocol (SIP). This document updates the normative guidance of RFC 3261 to require the Advanced Encryption Standard (AES) for S/MIME.

RFC 3261は現在、セッション開始プロトコル（SIP）におけるS/MIMEの実装のための必須の衝撃的な暗号化として3DEを指定しています。このドキュメントは、RFC 3261の規範的ガイダンスを更新して、S/MIMEの高度な暗号化標準（AES）を要求します。

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2. Terminology  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3. S/MIME Ciphersuite Requirements for SIP  . . . . . . . . . . . . 3
   4. Security Considerations  . . . . . . . . . . . . . . . . . . . . 3
   5. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
      5.1.  Normative References . . . . . . . . . . . . . . . . . . . 4
      5.2.  Informative References . . . . . . . . . . . . . . . . . . 4
   6. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . . 4
   7. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
   8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 6

1. Introduction

1. はじめに

The Session Initiation Protocol (SIP) specification (RFC 3261 [1]) currently details optional support (a normative MAY) for the use of secure MIME, or S/MIME (RFC 2633 [8]). Since RFC 3261 was published, the S/MIME specification and the underlying Cryptographic Message Syntax (CMS, RFC 3369 [3]) have undergone some revision. Ongoing work has identified AES as a algorithm that might be used for content encryption in S/MIME.

セッション開始プロトコル（SIP）仕様（RFC 3261 [1]）は現在、安全なMIMEまたはS/MIME（RFC 2633 [8]）を使用するためのオプションのサポート（規範5月）を詳述しています。RFC 3261が公開されて以来、S/MIME仕様と基礎となる暗号化メッセージの構文（CMS、RFC 3369 [3]）が何らかの修正を受けました。進行中の作業により、AEはS/MIMEのコンテンツ暗号化に使用される可能性のあるアルゴリズムとして特定されています。

The Advanced Encryption Standard (AES [6]) is widely believed to be faster than Triple-DES (3DES, which has previously been mandated for usage with S/MIME) and to be comparably secure. AES is also believed to have comparatively low memory requirements, which makes it suitable for use in mobile or embedded devices, an important use-case for SIP.

高度な暗号化標準（AES [6]）は、トリプルデス（3DES、以前はS/MIMEで使用されていたために義務付けられていた）よりも高速であると広く信じられており、同等の安全であると考えられています。また、AEは比較的低いメモリ要件を持っていると考えられているため、SIPの重要なユースケースであるモバイルまたは組み込みデバイスでの使用に適しています。

As an additional consideration, the SIP specification has a recommendation (normative SHOULD) for support of Transport Layer Security (TLS, RFC 2246 [7]). TLS support in SIP requires the usage of AES. That means that currently, implementations that support both TLS and S/MIME must support both 3DES and AES. A similar duplication of effort exists with DSS in S/MIME as a digital signature algorithm (the mandatory TLS ciphersuite used by SIP requires RSA). Unifying the ciphersuite and signature algorithm requirements for TLS and S/MIME would simplify security implementations.

追加の考慮事項として、SIP仕様には、輸送層のセキュリティをサポートするための推奨事項（規範的必要）があります（TLS、RFC 2246 [7]）。SIPでのTLSサポートには、AESの使用が必要です。つまり、TLSとS/MIMEの両方をサポートする実装は、3DEとAEの両方をサポートする必要があることを意味します。デジタル署名アルゴリズムとしてのS/MIMEのDSSには、同様の努力の複製が存在します（SIPで使用される必須のTLS ciphersuiteにはRSAが必要です）。TLSおよびS/MIMEのCiphersuiteおよび署名アルゴリズムの要件を統合すると、セキュリティの実装が簡素化されます。

It is therefore desirable to bring the S/MIME requirement for SIP into parity with ongoing work on the S/MIME standard, as well as to unify the algorithm requirements for TLS and S/MIME. To date, S/MIME has not yet seen widespread deployment in SIP user agents, and therefore the minimum ciphersuite for S/MIME could be updated without obsoleting any substantial deployments of S/MIME for SIP (in fact, these changes will probably make support for S/MIME easier). This document therefore updates the normative requirements for S/MIME in RFC 3261.

したがって、S/MIME標準で進行中の作業でSIPのSIP要件をパリティに導き、TLSおよびS/MIMEのアルゴリズム要件を統一することが望ましい。現在までに、S/MIMEはSIPユーザーエージェントでの広範な展開をまだ見ていないため、S/MIMEの最小シファースーツは、SIP用のS/MIMEの実質的な展開を廃止することなく更新できます（実際、これらの変更はおそらくサポートを行うでしょうs/mimeのために簡単です）。したがって、このドキュメントは、RFC 3261のS/MIMEの規範的要件を更新します。

Note that work on these revisions in the S/MIME working group is still in progress. This document will continue to track that work as it evolves. By initiating this process in the SIP WG now, we provide an early opportunity for input into the proposed changes and give implementers some warning that the S/MIME requirements for SIP are potentially changing.

S/MIMEワーキンググループのこれらの改訂版の作業はまだ進行中であることに注意してください。このドキュメントは、進化するにつれてその作業を追跡し続けます。SIP WGでこのプロセスを開始することにより、提案された変更に入力する早期の機会を提供し、実装者にSIPのS/MIME要件が潜在的に変化しているという警告を提供します。

2. Terminology

2. 用語

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant SIP implementations.

このドキュメントでは、キーワードは「必要はない」、「必須」、「「必要」」、「しなければ」、「そうしない」、「そうは思わない」、「そうでない」、「推奨」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [2]に記載されているように解釈され、準拠したSIP実装の要件レベルを示します。

3. S/MIME Ciphersuite Requirements for SIP

3. SIPのS/MIME CIPHERSUITE要件

The following updates the text of RFC 3261 Section 23.3, specifically the fifth bullet point. The text currently reads:

以下は、RFC 3261セクション23.3のテキスト、特に5番目の箇条書きを更新します。テキストは現在読みます：

o S/MIME implementations MUST at a minimum support SHA1 as a digital signature algorithm, and 3DES as an encryption algorithm. All other signature and encryption algorithms MAY be supported. Implementations can negotiate support for these algorithms with the "SMIMECapabilities" attribute.

o S/MIMEの実装は、デジタル署名アルゴリズムとしてSHA1を最小限に抑え、3DESを暗号化アルゴリズムとしてサポートする必要があります。他のすべての署名および暗号化アルゴリズムがサポートされる場合があります。実装は、これらのアルゴリズムのサポートを「SmimeCapability」属性と交渉することができます。

This text is updated with the following:

このテキストは、次のように更新されます。

S/MIME implementations MUST at a minimum support RSA as a digital signature algorithm and SHA1 as a digest algorithm [5], and AES as an encryption algorithm (as specified in [4]. For key transport, S/MIME implementations MUST support RSA key transport as specified in section 4.2.1. of [5]. S/MIME implementations of AES MUST support 128-bit AES keys, and SHOULD support 192 and 256-bit keys. Note that the S/MIME specification [8] mandates support for 3DES as an encryption algorithm, DH for key encryption and DSS as a signature algorithm. In the SIP profile of S/MIME, support for 3DES, DH and DSS is RECOMMENDED but not required. All other signature and encryption algorithms MAY be supported. Implementations can negotiate support for algorithms with the "SMIMECapabilities" attribute.

S/MIMEの実装は、デジタル署名アルゴリズムとしてRSAを最小限にサポートし、Digestアルゴリズム[5]としてSHA1として、暗号化アルゴリズムとしてのAES（[4]で指定されています。キートランスポートの場合、S/MIME実装はRSAをサポートする必要があります。[5]のセクション4.2.1。S/MIMEのAEの実装で指定されているキートランスポートは、128ビットAESキーをサポートする必要があり、192および256ビットキーをサポートする必要があります。S/MIME仕様[8]が命令することに注意暗号化アルゴリズムとしての3DEのサポート、キー暗号化のDH、署名アルゴリズムとしてのDSSのサポート。S/MIMEのSIPプロファイルでは、3DES、DH、DSSのサポートが推奨されますが、必須ではありません。実装は、「SmimeCapability」属性を使用してアルゴリズムのサポートをネゴシエートすることができます。

Since SIP is 8-bit clean, all implementations MUST use 8-bit binary Content-Transfer-Encoding for S/MIME in SIP. Implementations MAY also be able to receive base-64 Content-Transfer-Encoding.

SIPは8ビットクリーンであるため、すべての実装は、SIPでS/MIMEに8ビットのバイナリコンテンツ移動エンコードを使用する必要があります。実装は、ベース64コンテンツ転送エンコードを受信することもできます。

4. Security Considerations

4. セキュリティに関する考慮事項

The migration of the S/MIME requirement from Triple-DES to AES is not known to introduce any new security considerations.

S/MIME要件のTriple-DESからAESへの移行は、新しいセキュリティ上の考慮事項を導入することは知られていません。

5. References

5. 参考文献

5.1. Normative References

5.1. 引用文献

[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

[1] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。

[2] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.

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

[3] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, August 2002.

[3] Housley、R。、「暗号化メッセージ構文（CMS）」、RFC 3369、2002年8月。

[4] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.

[4] Schaad、J。、「暗号化メッセージ構文（CMS）での高度な暗号化標準（AES）暗号化アルゴリズムの使用」、RFC 3565、2003年7月。

[5] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3394, August 2002.

[5] Housley、R。、「暗号化メッセージ構文（CMS）アルゴリズム」、RFC 3394、2002年8月。

5.2. Informative References

5.2. 参考引用

[6] National Institute of Standards & Technology, "Advanced Encryption Standard (AES).", FIPS 197, November 2001.

[6] 国立標準研究所、「高度な暗号化標準（AES）」、FIPS 197、2001年11月。

[7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.

[7] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。

[8] Ramsdell, B., Ed., "S/MIME Version 3.1 Message Specification", RFC 3851, July 2004.

[8] Ramsdell、B.、ed。、「S/Mimeバージョン3.1メッセージ仕様」、RFC 3851、2004年7月。

6. Acknowledgments

6. 謝辞

Thanks to Rohan Mahy, Gonzalo Camarillo, and Eric Rescorla for review of this document.

この文書のレビューをしてくれたRohan Mahy、Gonzalo Camarillo、およびEric Rescorlaに感謝します。

7. Author's Address

7. 著者の連絡先

Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US

Jon Peterson Neustar、Inc。1800 Sutter St Suite 570 Concord、CA 94520 US

   Phone: +1 925/363-8720
   EMail: jon.peterson@neustar.biz
   URI:   http://www.neustar.biz/

8. Full Copyright Statement

8. 完全な著作権声明

Copyright (C) The Internet Society (2004). 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.

著作権（c）The Internet Society（2004）。この文書は、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は、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。