[要約] 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

Digest-MD5を歴史的に移動します

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で指定されているDigest-MD5の単純な認証とセキュリティ層(SASL)メカニズムの問題について説明しています。SASLメカニズムのIANAレジストリでは、RFC 2831を歴史的状態に移動することで、Digest-MD5を廃止します。

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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http://www.rfc-editor.org/info/rfc6331で取得できます。

Copyright Notice

著作権表示

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

Copyright(c)2011 IETF Trustおよび文書著者として特定された人。全著作権所有。

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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.

このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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]は、SASLプロファイルを持つプロトコルのシンプルな認証およびセキュリティレイヤー(SASL)[RFC4422]メカニズムとして、HTTP Digest認証[RFC2617]をどのように使用できるかを定義します。CRAM-MD5 [RFC2195]の改善と、Web、電子メール、Lightweight Directory Access Protocol(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

1. メカニズムには、オプションとモードが多すぎます。それらのいくつかは十分に説明されておらず、広く実装されていません。たとえば、Digest-MD5を使用すると、「QOP」ディレクティブが複数の値を含めることができますが、複数のQOPディレクティブを指定することもできます。複数のオプションの処理は指定されていないため、操作性の高い問題がわずかになります。いくつかの実装は複数のQOP値を1つに融合させ、他の実装は複数のQOPをエラーとして扱います。別の例は、空の承認IDの使用です。SASLでは、空の承認アイデンティティは、クライアントが認証アイデンティティとして承認する意思があることを意味します。ドキュメントは明確ではありません

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.

Authzidは省略する必要があります。または、これを伝えるために空の値で指定できる場合は省略する必要があります。HTTPダイジェストとの後方互換性の要件は、状況がさらに悪化することを意味します。たとえば、Digest-MD5には、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 [RFC0822]のABNFを使用します。これにより、追加のコンストラクトが可能になり、「暗黙の折りたたみ式」を多くの場所に挿入できます。[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ドキュメントでは、レルムの名前をどのように命名するか、さらに重要なことには、ユーザーインターフェイス(UIS)にどのように入力できるかについてのガイダンスは提供されません。その結果、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パスワードデータベースと互換性がありません。2番目に、ユーザー名を変更すると、内側のハッシュが無効になります。

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)攻撃に対して脆弱になります。サポートされているQOPSまたは暗号。

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.

C. SASLPREP [RFC4013]またはユーザー名とパスワードのその他のタイプのユニコード文字正規化のサポート。元のDigest-MD5ドキュメントはSASLPREPを前もって前にしており、ユニコード文字の正規化を推奨していません。

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].

A. MD5ハッシュは、一般的なハードウェア[RFC6151]を使用して、Digest-MD5に対するブルートフォース攻撃を簡単にするのに十分な弱いです。

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ダイジェスト認証メカニズムにすでに存在していることに注意してください。

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は拡張可能なメカニズムとして定義されるため、上記の問題のほとんどを修正することができます。ただし、これにより、すでに複雑なメカニズムの実装の複雑さがさらに向上するため、努力はコストに見合うだけの価値がありません。さらに、「固定された」ダイジェスト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が実装されているため、さらなる標準化の合理的な候補ではなく、1つまたは複数の新しいパスワードベースの候補者を支持して非推奨されるため、Digest-MD5を廃止することを推奨しています。現在設計中のメカニズム。

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]の塩分チャレンジ応答認証メカニズム(スクラム)ファミリーは、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は、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].

著者は、クリス・ニューマン、サイモン・ジョセフソン、カート・ゼイレンガ、ショーン・ターナー、アビジット・メノンセンが提供するフィードバックを感謝して認めています。特に[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] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。、およびL. Stewart、「HTTP認証:基本および消化アクセス認証」、RFC 2617、1999年6月。

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

[RFC2831] Leach、P。およびC. Newman、「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:ラテンアルファベットNo. 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] Crocker、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は、Simple Challenge/Responseの拡張を承認します」、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] Orman、H。およびP. Hoffman、「対称キーの交換に使用される公共キーの強度の決定」、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] Melnikov、A。およびK. Zeilenga、「Simple Authentication and Security Layer(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] Crocker、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] Newman、C.、Menon-Sen、A.、Melnikov、A.、およびN. Williams、「Salted Challenge Response認証メカニズム(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] Turner、S。およびL. Chen、「MD5 Message-Digestおよび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、「Stream Cipher RC4のテストベクトル」、RFC 6229、2011年5月。

Author's Address

著者の連絡先

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

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

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