RFC 6331 - Moving DIGEST-MD5 to Historic 日本語訳

URL : https://tools.ietf.org/html/rfc6331
タイトル : RFC 6331 - 歴史的にDIGEST-MD5を移動します
翻訳編集 : 自動生成

Internet Engineering Task Force (IETF)                       A. Melnikov
Request for Comments: 6331                                 Isode Limited
Obsoletes: 2831                                                July 2011
Category: Informational
ISSN: 2070-1721

                     Moving DIGEST-MD5 to Historic

Abstract

抽象

This memo describes problems with the DIGEST-MD5 Simple Authentication and Security Layer (SASL) mechanism as specified in RFC 2831. It marks DIGEST-MD5 as OBSOLETE in the IANA Registry of SASL mechanisms and moves RFC 2831 to Historic status.

RFC 2831で指定されたこのメモは、それはSASLメカニズムのIANAレジストリにOBSOLETEとしてDIGEST-MD5をマークし、歴史的な状況にRFC 2831を移動DIGEST-MD5簡易認証セキュリティー層（SASL）メカニズムの問題を説明します。

Status of This Memo

このメモのステータス

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6331.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6331で取得することができます。

著作権表示

著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

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.

この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。

Table of Contents

   1.    Introduction and Overview . . . . . . . . . . . . . . . . . . 2
   2.    Security Considerations . . . . . . . . . . . . . . . . . . . 5
   3.    IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
   4.    Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . 5
   5.    References  . . . . . . . . . . . . . . . . . . . . . . . . . 5
   5.1.  Normative References  . . . . . . . . . . . . . . . . . . . . 5
   5.2.  Informative References  . . . . . . . . . . . . . . . . . . . 5

1. Introduction and Overview

1.はじめにと概要

[RFC2831] defines how HTTP Digest Authentication [RFC2617] can be used as a Simple Authentication and Security Layer (SASL) [RFC4422] mechanism for any protocol that has a SASL profile. It was intended both as an improvement over CRAM-MD5 [RFC2195] and as a convenient way to support a single authentication mechanism for web, email, the Lightweight Directory Access Protocol (LDAP), and other protocols. While it can be argued that it is an improvement over CRAM-MD5, many implementors commented that the additional complexity of DIGEST-MD5 makes it difficult to implement fully and securely.

[RFC2831]はHTTPダイジェスト認証[RFC2617]は簡易認証とセキュリティ層（SASL）SASLプロファイルを有する任意のプロトコルのために[RFC4422]メカニズムとして使用することができる方法を定義します。これは、CRAM-MD5 [RFC2195]に比べて改善としてやWeb、電子メール、ライトウェイトディレクトリアクセスプロトコル（LDAP）、および他のプロトコルのための単一の認証メカニズムをサポートする便利な方法として、両方を意図していました。それはCRAM-MD5の改良であると主張することができますが、多くの実装は、DIGEST-MD5の追加の複雑さは、それが困難な完全かつ安全に実現することができるとコメントしました。

Below is an incomplete list of problems with the DIGEST-MD5 mechanism as specified in [RFC2831]:

以下[RFC2831]で指定されるようにDIGEST-MD5機構の問題の不完全なリストであります：

1. The mechanism has too many options and modes. Some of them are not well described and are not widely implemented. For example, DIGEST-MD5 allows the "qop" directive to contain multiple values, but it also allows for multiple qop directives to be specified. The handling of multiple options is not specified, which results in minor interoperability problems. Some implementations amalgamate multiple qop values into one, while others treat multiple qops as an error. Another example is the use of an empty authorization identity. In SASL, an empty authorization identity means that the client is willing to authorize as the authentication identity. The document is not clear on whether the authzid must be omitted or if it can be specified with an empty value to convey this. The requirement for backward compatibility with HTTP Digest means that the situation is even worse. For example, DIGEST-MD5 requires all usernames/passwords that can be entirely represented in the ISO-8859-1 charset to be down converted from UTF-8 [RFC3629] to ISO-8859-1 [ISO-8859-1]. Another example is the use of quoted strings. Handling of characters that need escaping is not properly described, and the DIGEST-MD5 document has no examples to demonstrate correct behavior.

1.メカニズムは、あまりにも多くのオプションとモードがあります。それらのいくつかは、十分に記載されておらず、広く実装されていません。例えば、DIGEST-MD5は「QOP」ディレクティブは、複数の値を含めることができますが、複数のQOPディレクティブを指定することもできます。マイナーな相互運用性の問題につながる指定されていない複数のオプションの取扱い、。他のものはエラーとして複数のQOPを治療しながら、いくつかの実装は、一つに複数QOP値を合併します。別の例は、空の認証アイデンティティの使用です。 SASLでは、空の許可IDは、クライアントが認証IDとして認可する意志があることを意味しています。文書はauthzidは省略されなければならないかどうかについては明らかではないか、それが空の値を指定することができる場合は、これを伝えるために。 HTTPダイジェストとの下位互換性のための要件は、状況はさらに悪くなることを意味しています。例えば、DIGEST-MD5は、完全にダウンISO-8859-1 [ISO-8859-1]にUTF-8 [RFC3629]から変換するISO-8859-1文字セットで表現できるすべてのユーザー名/パスワードを必要とします。別の例は、引用符で囲まれた文字列を使用することです。エスケープ必要文字の扱いが正しく記述されていない、とDIGEST-MD5の文書は正しい動作を実証するための何の例がありません。

2. The DIGEST-MD5 document uses ABNF from RFC 822 [RFC0822], which allows an extra construct and allows for "implied folding whitespace" to be inserted in many places. The difference from a more common ABNF defined in [RFC5234] is confusing for some implementors. As a result, many implementations do not accept folding whitespace in many places where it is allowed.

2. DIGEST-MD5の文書は、余分な構築を可能にし、多くの場所に挿入される「暗黙折り空白」を可能にするRFC 822からABNF [RFC0822]を使用します。 [RFC5234]で定義されたより一般的なABNFとの違いは、いくつかの実装のために混乱されます。その結果、多くの実装は、それが許可されている多くの場所で空白を折りたたみ受け付けておりません。

3. The DIGEST-MD5 document uses the concept of a "realm" to define a collection of accounts. A DIGEST-MD5 server can support one or more realms. The DIGEST-MD5 document does not provide any guidance on how realms should be named and, more importantly, how they can be entered in User Interfaces (UIs). As a result, many DIGEST-MD5 clients have confusing UIs, do not allow users to enter a realm, and/or do not allow users to pick one of the server-supported realms.

3. DIGEST-MD5の文書は、アカウントのコレクションを定義するには、「領域」の概念を使用しています。 DIGEST-MD5サーバは、1つまたは複数のレルムをサポートすることができます。 DIGEST-MD5の文書は、彼らがユーザーインターフェイス（UI）で入力することができますどのように、より重要なのは、王国が命名する方法上の任意のガイダンスを提供していません。その結果、多くのDIGEST-MD5クライアントが紛らわしいUIを持って、ユーザーがレルムを入力することはできません、および/またはユーザがサーバ・サポートしている領域のいずれかを選択することはできません。

4. Use of username in the inner hash is problematic. The inner hash of DIGEST-MD5 is an MD5 hash of colon-separated username, realm, and password. Implementations may choose to store inner hashes instead of clear text passwords. This has some useful properties, such as protection from compromise of authentication databases containing the same username and password on other servers if a server with the username and password is compromised; however, this is rarely done in practice. First, the inner hash is not compatible with widely deployed Unix password databases, and second, changing the username would invalidate the inner hash.

内部ハッシュにユーザー名の4.には問題があります。 DIGEST-MD5のハッシュ内部には、コロンで区切られたユーザ名、レルムおよびパスワードのMD5ハッシュです。実装は、内側ハッシュの代わりに、クリアテキストのパスワードを格納することもできます。これは、ユーザ名とパスワードを使用して、サーバーが侵害された場合、他のサーバーで同じユーザー名とパスワードを含む認証データベースの妥協からの保護など、いくつかの有用な性質を持っています。しかし、これは実際にはほとんど行われません。まず、内部ハッシュが広く展開されているUNIXのパスワードデータベースと互換性がありません、そして第二に、ユーザー名を変更すると、内側のハッシュを無効にします。

5. Description of DES/3DES [DES] and RC4 security layers are inadequate to produce independently developed interoperable implementations. In the DES/3DES case, this is partly a problem with existing DES APIs.

5. DES / 3DESの説明[DES]およびRC4セキュリティ層は、独立して開発され、相互運用可能な実装を生成するのに不十分です。 DES / 3DESの場合、これは、部分的に、既存のDESのAPIの問題です。

6. DIGEST-MD5 outer hash (the value of the "response" directive) does not protect the whole authentication exchange, which makes the mechanism vulnerable to "man-in-the-middle" (MITM) attacks, such as modification of the list of supported qops or ciphers.

6. DIGEST-MD5外側ハッシュ（ "応答" 指令の値）は、の変形例 "のman-in-the-middle"（MITM）攻撃に対して脆弱機構を作る全体認証交換を保護しませんサポートのQOPまたは暗号のリスト。

7. The following features are missing from DIGEST-MD5, making it insecure or unsuitable for use in protocols:

7.次の機能は、それが安全でないかのプロトコルで使用するため不適当で、DIGEST-MD5から欠落しています：

A. Channel bindings [RFC5056].

A.チャネルバインディング[RFC5056]。

B. Hash agility (i.e., no easy way to replace the MD5 hash function with another one).

B.ハッシュアジリティ（即ち、別のものとのMD5ハッシュ関数を置き換えるための簡単な方法）。

C. Support for SASLPrep [RFC4013] or any other type of Unicode character normalization of usernames and passwords. The original DIGEST-MD5 document predates SASLPrep and does not recommend any Unicode character normalization.

SASLPrep [RFC4013]またはユーザ名とパスワードのUnicode文字の正規化の他のタイプのためのC.サポート。元DIGEST-MD5文書はSASLPrepに先行し、任意のUnicode文字の正規化を推奨していません。

8. The cryptographic primitives in DIGEST-MD5 are not up to today's standards, in particular:

8. DIGEST-MD5で暗号プリミティブは特に、今日の基準までではありません。

       A.  The MD5 hash is sufficiently weak to make a brute force
           attack on DIGEST-MD5 easy with common hardware [RFC6151].

B. The RC4 algorithm is prone to attack when used as the security layer without discarding the initial key stream output [RFC6229].

B. RC4アルゴリズムは、最初のキーストリーム出力[RFC6229]を破棄せずにセキュリティ層として用いた場合に攻撃する傾向があります。

C. The DES cipher for the security layer is considered insecure due to its small key space [RFC3766].

C.は、セキュリティ層のためのDES暗号は、その小さな鍵空間[RFC3766]に安全ではないと考えられています。

Note that most of the problems listed above are already present in the HTTP Digest authentication mechanism.

上記の問題のほとんどは、HTTP Digest認証メカニズムにすでに存在していることに注意してください。

Because DIGEST-MD5 is defined as an extensible mechanism, it is possible to fix most of the problems listed above. However, this would increase implementation complexity of an already complex mechanism even further, so the effort is not worth the cost. In addition, an implementation of a "fixed" DIGEST-MD5 specification would likely either not interoperate with any existing implementation of [RFC2831] or would be vulnerable to various downgrade attacks.

DIGEST-MD5は、拡張可能なメカニズムとして定義されているので、上記の問題のほとんどを解決することが可能です。しかし、これはさらに、すでに複雑な機構の実装の複雑さを増加させるので、労力、コスト価値はありません。また、「固定」DIGEST-MD5仕様の実装は、おそらくいずれか[RFC2831]の既存の実装と相互運用しないであろう、または様々なダウングレード攻撃に対して脆弱であろう。

Note that despite DIGEST-MD5 seeing some deployment on the Internet, this specification recommends obsoleting DIGEST-MD5 because DIGEST-MD5, as implemented, is not a reasonable candidate for further standardization and should be deprecated in favor of one or more new password-based mechanisms currently being designed.

DIGEST-MD5は、インターネット上でいくつかの展開を見てもかかわらず、この仕様は、DIGEST-MD5ので、DIGEST-MD5を時代遅れに推奨し、実装され、さらに標準化のための合理的な候補ではないと1つまたは複数の新しいパスワードベースの賛成で廃止されるべきであることに注意してくださいメカニズムは、現在設計されています。

The Salted Challenge Response Authentication Mechanism (SCRAM) family of SASL mechanisms [RFC5802] has been developed to provide similar features as DIGEST-MD5 but with a better design.

SASLメカニズム[RFC5802]の塩漬けチャレンジレスポンス認証メカニズム（SCRAM）ファミリーは、DIGEST-MD5などのより良いデザインと同様の機能を提供するために開発されてきました。

2. Security Considerations

2.セキュリティの考慮事項

Security issues are discussed throughout this document.

セキュリティ問題はこの文書を通して議論されています。

3. IANA Considerations

3. IANAの考慮事項

IANA has changed the "Intended usage" of the DIGEST-MD5 mechanism registration in the SASL mechanism registry to OBSOLETE. The SASL mechanism registry is specified in [RFC4422] and is currently available at:

IANAはOBSOLETEにSASLメカニズムのレジストリでDIGEST-MD5メカニズム登録の「使用目的」に変更されました。 SASLメカニズムのレジストリは、[RFC4422]で指定し、で現在利用可能です。

http://www.iana.org/assignments/sasl-mechanisms

ｈっｔｐ：／／ｗっｗ。いあな。おｒｇ／あっしｇんめんｔｓ／さｓｌーめちゃにｓｍｓ

4. Acknowledgements

4.謝辞

The author gratefully acknowledges the feedback provided by Chris Newman, Simon Josefsson, Kurt Zeilenga, Sean Turner, and Abhijit Menon-Sen. Various text was copied from other RFCs, in particular, from [RFC2831].

作者は感謝クリス・ニューマン、サイモンJosefsson氏、クルトZeilenga、ショーン・ターナー、およびAbhijitメノンセンによって提供されるフィードバックを認めます。様々なテキストは[RFC2831]から、特に、他のRFCからコピーされました。

5. References

5.参考文献

5.1. Normative References

5.1. 引用規格

[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.

[RFC2617]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、 "HTTP認証：基本とダイジェストアクセス認証" 、RFC 2617、1999年6月。

[RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.

[RFC2831]リーチ、P.とC.ニューマン、 "SASLメカニズムとしてダイジェスト認証を使用する"、RFC 2831、2000年5月。

5.2. Informative References

5.2. 参考文献

[DES] National Institute of Standards and Technology, "Data Encryption Standard (DES)", FIPS PUB 46-3, October 1999.

[DES]米国国立標準技術研究所、 "データ暗号化規格（DES）"、FIPS PUBの46-3、1999年10月。

[ISO-8859-1] International Organization for Standardization, "Information technology - 8-bit single-byte coded graphic character sets - Part 1: Latin alphabet No. 1", ISO/IEC 8859-1, 1998.

[ISO-8859-1]国際標準化機構、 "情報技術 - 8ビットシングルバイトコード化されたグラフィック文字集合 - 第1部：ラテンアルファベット1号"、ISO / IEC 8859-1、1998。

[RFC0822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.

[RFC0822]クロッカー、D.、 "ARPAインターネットテキストメッセージの形式の規格"、STD 11、RFC 822、1982年8月。

[RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997.

[RFC2195] Klensin、J.、Catoe、R.、およびP. Krumviede、 "単純なチャレンジ/レスポンスのためのIMAP / POP許可拡張子"、RFC 2195、1997年9月。

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.

[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。

[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.

[RFC3766]オーマン、H.、およびP.ホフマン、 "対称鍵を交換するために使用公開鍵の強さを測定"、BCP 86、RFC 3766、2004年4月。

[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.

[RFC4013] Zeilenga、K.、 "SASLprep：ユーザ名とパスワードのためのstringprepプロフィール"、RFC 4013、2005年2月。

[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.

[RFC4422]メルニコフ、A.およびK. Zeilenga、 "簡易認証セキュリティー層（SASL）"、RFC 4422、2006年6月。

[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.

"チャネルを確保するチャネルバインディングの使用について" [RFC5056]ウィリアムズ、N.、RFC 5056、2007年11月。

[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。

[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010.

[RFC5802]ニューマン、C.、メノンセン、A.、メルニコフ、A.、およびN.ウィリアムズ、 "塩蔵チャレンジレスポンス認証メカニズム（SCRAM）SASLとGSS-APIメカニズム"、RFC 5802、2010年7月。

[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 2011.

[RFC6151]ターナー、S.とL.チェン、 "MD5メッセージダイジェストとHMAC-MD5アルゴリズムのための更新されたセキュリティ上の考慮事項"、RFC 6151、2011年3月。

[RFC6229] Strombergson, J. and S. Josefsson, "Test Vectors for the Stream Cipher RC4", RFC 6229, May 2011.

[RFC6229] Strombergson、J.およびS. Josefsson氏、 "ストリーム暗号RC4のテストベクター"、RFC 6229、2011年05月。

Author's Address

著者のアドレス

Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK

アレクセイ・メルニコフISODE限定5キャッスルビジネス村の36の駅道ハンプトン、ミドルTW12 2BX英国

EMail: Alexey.Melnikov@isode.com URI: http://www.melnikov.ca/

電子メール：Alexey.Melnikov@isode.com URI：http://www.melnikov.ca/