この文書はRFC 4635の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。
Network Working Group D. Eastlake 3rd Request for Comments: 4635 Motorola Laboratories Category: Standards Track August 2006 HMAC SHA TSIG Algorithm Identifiers HMAC SHA TSIG アルゴリズム識別子 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. この文書はインターネット共同体のためのインターネット標準化中のプロト コルを指定し、そして改良のために議論と提案を求めます。このプロトコル と標準化状態と状況は「インターネット公式プロトコル標準」(STD1) の最新版を参照してください。このメモの配布は無制限です。 Copyright Notice 著作権表示 Copyright (C) The Internet Society (2006). Abstract 要約 Use of the Domain Name System TSIG resource record requires specification of a cryptographic message authentication code. Currently, identifiers have been specified only for HMAC MD5 (Hashed Message Authentication Code, Message Digest 5) and GSS (Generic Security Service) TSIG algorithms. This document standardizes identifiers and implementation requirements for additional HMAC SHA (Secure Hash Algorithm) TSIG algorithms and standardizes how to specify and handle the truncation of HMAC values in TSIG. ドメインネームシステムTSIG資源レコードの使用は暗号メッセージ認証 コードの仕様を必要とします。現在、TSIGアルゴリズムで、HMAC MD5 (ハッシュメッセージ認証コード、メッセージダイジェスト5)とGSS (一般的セキュリティサービス)だけが指定さています。この文書は、追加 のHMAC SHA(安全なハッシュアルゴリズム)TSIGアルゴリズムのための 識別子と実装条件を標準化し、TSIGでHMAC値の切り詰め法の指定と処理 方法を標準化します。 Table of Contents 目次 1. Introduction 1. はじめに 2. Algorithms and Identifiers 2. アルゴリズムと識別子 3. Specifying Truncation 3. 切詰めの指定 3.1. Truncation Specification 3.1. 切詰め仕様 4. TSIG Truncation Policy and Error Provisions 4. TSIG切詰めポリシとエラー条項 5. IANA Considerations 5. IANAの考慮 6. Security Considerations 6. セキュリティの考察 7. Normative References 7. 参照する参考文献 8. Informative References. 8. 有益な参考文献 1. Introduction 1. はじめに [RFC2845] specifies a TSIG Resource Record (RR) that can be used to authenticate DNS (Domain Name System [STD13]) queries and responses. This RR contains a domain name syntax data item that names the authentication algorithm used. [RFC2845] defines the HMAC-MD5.SIG-ALG.REG.INT name for authentication codes using the HMAC (Hashed Message Authentication Code) [RFC2104] algorithm with the MD5 (Message Digest 5) [RFC1321] hash algorithm. IANA has also registered "gss-tsig" as an identifier for TSIG authentication where the cryptographic operations are delegated to the Generic Security Service (GSS) [RFC3645]. [RFC2845]がDNS(ドメイン名システム[STD13])の問合せと応答を認証す るために使うことができるTSIG資源レコード(RR)を指定します。こ の資源レコードは使われた認証アルゴリズムの名前を持つドメイン名構文デー タ項目を含みます。[RFC2845]が認証コードがMD5(メッセージダイジェス ト5)[RFC1321]ハッシュアルゴリズムを使うHMAC(Hashedなメッセージ 認証コード)[RFC2104]アルゴリズムで使う名前のHMAC-MD5.SIG-ALG.REG.INT を定義します。IANAはまた、一般的セキュリティサービス(GSS) [RFC3645]に委任される暗号オペレーションのTSIG認証のために "gss-tsig"を識別子として登録しました。 Note that use of TSIG presumes prior agreement, between the resolver and server involved, as to the algorithm and key to be used. TSIGが使われるという事は、関連するリゾルバとサーバ間での事前合 意があると仮定されていることに注意してください、アルゴリズムと鍵も 同様です。 In Section 2, this document specifies additional names for TSIG authentication algorithms based on US NIST SHA (United States, National Institute of Science and Technology, Secure Hash Algorithm) algorithms and HMAC and specifies the implementation requirements for those algorithms. 2章で、この文書はUS NIST SHA (合衆国、科学技術国立研究所、安全な ハッシュアルゴリズム)アルゴリズムとHMACに基づくTSIG認証ア ルゴリズムの追加の名前を指定して、そしてそれらのアルゴリズムのため の実装必要条件を指定します。 In Section 3, this document specifies the effect of inequality between the normal output size of the specified hash function and the length of MAC (Message Authentication Code) data given in the TSIG RR. In particular, it specifies that a shorter-length field value specifies truncation and that a longer-length field is an error. 3章で、この文書は指定されたハッシュ機能の標準的な出力のサイズとTS IG資源レコードで与えられたMAC(メッセージ認証コード)データ長さ の間の不均等の効果を指定します。特に、より短い長さのフィールド値が切 詰めを指定し、より長い長さのフィールドがエラーであることを明示します。 In Section 4, policy restrictions and implications related to truncation are described and specified, as is a new error code to indicate truncation shorter than that permitted by policy. 4章で、ポリシ制限と切詰めに関係する暗黙の了解が記述され、そして、ポ リシによって認めたより短い切詰めを示すための新しいエラーコードが指定 されます。 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY", in this document are to be interpreted as described in [RFC2119]. この文書のキーワード"MUST"と"MUST NOT"と"SHOULD"と"SHOULD NOT"と"MAY" は[RFC2119]で記述されるように解釈されるはずです。 2. Algorithms and Identifiers 2. アルゴリズムと識別子 TSIG Resource Records (RRs) [RFC2845] are used to authenticate DNS queries and responses. They are intended to be efficient symmetric authentication codes based on a shared secret. (Asymmetric signatures can be provided using the SIG RR [RFC2931]. In particular, SIG(0) can be used for transaction signatures.) Used with a strong hash function, HMAC [RFC2104] provides a way to calculate such symmetric authentication codes. The only specified HMAC-based TSIG algorithm identifier has been HMAC-MD5.SIG- ALG.REG.INT, based on MD5 [RFC1321]. TSIG資源レコード(RR)[RFC2845]がDNSの問合せと応答を認証する ために使われます。それらは共有秘密鍵に基づく効率的な共有鍵認証を意図 します。(公開鍵署名はSIG資源レコード[RFC2931]を使って提供できます。 特に、SIG(0)は取引署名に使うことができます。)強いハッシュ関数 を使い、HMAC[RFC2104]はこのような共有鍵認証を計算する方法を提供し ます。唯一の指定されたHMACベースのTSIGアルゴリズム識別子は、 MD5[RFC1321]に基づくいて、HMAC-MD5.SIG-ALG.REG.INTでした。 The use of SHA-1 [FIPS180-2, RFC3174], which is a 160-bit hash, as compared with the 128 bits for MD5, and additional hash algorithms in the SHA family [FIPS180-2, RFC3874, RFC4634] with 224, 256, 384, and 512 bits may be preferred in some cases. This is because increasingly successful cryptanalytic attacks are being made on the shorter hashes. 128ビットのMD5と比較して、160ビットハッシュのSHA−1 [FIPS180-2, RFC3174]の使用は、また、追加のハッシュアルゴリズム、 224と256と384と512ビットのSHAファミリ[FIPS180-2, RFC3874, RFC4634]の使用が、ある場合には好まれるかもしれません。これ は短いハッシュで暗号攻撃の成功がより可能になっているからです。 Use of TSIG between a DNS resolver and server is by mutual agreement. That agreement can include the support of additional algorithms and criteria as to which algorithms and truncations are acceptable, subject to the restriction and guidelines in Sections 3 and 4 below. Key agreement can be by the TKEY mechanism [RFC2930] or some other mutually agreeable method. DNSリゾルバとサーバ間のTSIGの使用は相互の合意によります。その 合意は、3章と4章の制限とガイドラインの適用下で、追加のアルゴリズム のサポートとアルゴリズムと切詰めが受容できる基準を含めることができま す。鍵合意は処理鍵メカニズム[RFC2930]あるいは何か他の相互に合意できる 方法によって可能です。 The current HMAC-MD5.SIG-ALG.REG.INT and gss-tsig identifiers are included in the table below for convenience. Implementations that support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and MAY implement gss-tsig and the other algorithms listed below. 現在のHMAC-MD5.SIG-ALG.REG.INTとgss-tsig識別子は便利さのために下にテー ブルに含められます。TSIGをサポートする実装は同じくHMAC SHA1とHMAC SHA256を実装しなければならず(MUST)、そして gss-tsigと下にリストされた他のアルゴリズムを実装するかもしれません(MAY)。 Mandatory HMAC-MD5.SIG-ALG.REG.INT Optional gss-tsig Mandatory hmac-sha1 Optional hmac-sha224 Mandatory hmac-sha256 Optional hamc-sha384 Optional hmac-sha512 SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented. 96ビット(12オクテット)に切り落とされたSHA−1が実装されるべ きです(SHOULD)。 3. Specifying Truncation 3. 切詰めの指定 When space is at a premium and the strength of the full length of an HMAC is not needed, it is reasonable to truncate the HMAC output and use the truncated value for authentication. HMAC SHA-1 truncated to 96 bits is an option available in several IETF protocols, including IPsec and TLS. スペースが貴重で、HMACの全長の強さが必要ないとき、HMAC出力を 切詰めて、認証に切詰めた値を使うことは合理的です。96ビットに切詰め たHMAC SHA−1はIPsecとTLSを含めて、いくつかのIETF プロトコルで利用可能なオプションです。 The TSIG RR [RFC2845] includes a "MAC size" field, which gives the size of the MAC field in octets. However, [RFC2845] does not specify what to do if this MAC size differs from the length of the output of HMAC for a particular hash function. Truncation is indicated by a MAC size less than the HMAC size, as specified below. TSIG資源レコード[RFC2845]はMACフィールドのオクテット数を与える 「MAC長」フィールドを含みます。しかしながら、もしこのMAC長が特 定のハッシュ関数のHMAC出力長とは違う場合、[RFC2845]は何をするべき か明示しません。下に指定されるように、HMACサイズ未満のMAC長は 切詰めを示します。 3.1. Truncation Specification 3.1. 切詰め仕様 The specification for TSIG handling is changed as follows: TSIGの取り扱いの仕様は次のように変えられます: 1. If "MAC size" field is greater than HMAC output length: 1. もし「MACサイズ」フィールドがHMAC出力長より大きいなら: This case MUST NOT be generated and, if received, MUST cause the packet to be dropped and RCODE 1 (FORMERR) to be returned. この場合は起きてはならず(MUST NOT)、そして、もし受信したらパ ケットは廃棄し、RCODE 1(FORMERR)を返すようにしなければなりま せん(MUST)。 2. If "MAC size" field equals HMAC output length: 2. もし「MACサイズ」フィールドがHMAC出力長に一致するなら: Operation is as described in [RFC2845], and the entire output HMAC output is present. オペレーションを[RFC2845]で記述されるように処理し、全HMAC 出力は存在しています。 3. "MAC size" field is less than HMAC output length but greater than that specified in case 4, below: 3. MACサイズ」フィールドはHMAC出力長より小さいが、下の4項で 指定されるものより大きいなら: This is sent when the signer has truncated the HMAC output to an allowable length, as described in RFC 2104, taking initial octets and discarding trailing octets. TSIG truncation can only be to an integral number of octets. On receipt of a packet with truncation thus indicated, the locally calculated MAC is similarly truncated and only the truncated values are compared for authentication. The request MAC used when calculating the TSIG MAC for a reply is the truncated request MAC. RFC2104で記述されるように、署名者が許されている長さに、 HMAC出力の最初のオクテットをの残し後のオクテットと捨てて、切詰 めたときこれは送られます。TSIGの切詰めはオクテットの最初にだけ 可能です。切詰めたパケットの受信はそれで示され、ローカルに計算され たMACも同様に切り詰められ、そして切詰められた値だけが認証のため に比較されます。TSIG MACを計算する時に使う要求MACは、切 詰められた要求MACです。 4. "MAC size" field is less than the larger of 10 (octets) and half the length of the hash function in use: 4. 「MACサイズ」フィールドは、10(オクテット)より大きい値より小 さく、かつ、使用中のハッシュ関数の半分の長さより小さい場合: With the exception of certain TSIG error messages described in RFC 2845, Section 3.2, where it is permitted that the MAC size be zero, this case MUST NOT be generated and, if received, MUST cause the packet to be dropped and RCODE 1 (FORMERR) to be returned. The size limit for this case can also, for the hash functions mentioned in this document, be stated as less than half the hash function length for hash functions other than MD5 and less than 10 octets for MD5. RFC2845の3.2章でMACサイズがゼロであるのを認められる ある特定のTSIGエラーを除き、この場合は生成されてはならず(MUST NOT)、もし受信したら、パケットは廃棄されねばならず(MUST)、RCODE 1 (FORMERR)を返送します。この文書で述べたハッシュ関数に対し、この 場合のサイズの限界は、MD5以外ではハッシュ関数の長さの半分以下で、 MD5では10オクテット以下と明記されます。 4. TSIG Truncation Policy and Error Provisions 4. TSIG切詰めポリシとエラー条項 Use of TSIG is by mutual agreement between a resolver and server. Implicit in such "agreement" are criterion as to acceptable keys and algorithms and, with the extensions in this document, truncations. Note that it is common for implementations to bind the TSIG secret key or keys that may be in place at a resolver and server to particular algorithms. Thus, such implementations only permit the use of an algorithm if there is an associated key in place. Receipt of an unknown, unimplemented, or disabled algorithm typically results in a BADKEY error. TSIGの使用はリゾルバとサーバ間の相互協定によります。このような 「合意」には許容できる鍵とアルゴリズムの基準と、この文書で拡張した 切り詰めです。リゾルバとサーバに保管されるTSIG秘密鍵を特定のア ルゴリズムに結び付けることは、実装に共通でであることに注意してくだ さい。それで、ある鍵に対し、実装は関連したアルゴリズムの使用を認め るだけです。未知やみ実装や障害のあるアルゴリズムの受信は一般にBADKEY エラーをもたらします。 Local policies MAY require the rejection of TSIGs, even though they use an algorithm for which implementation is mandatory. 実装が必須のアルゴリズムを使が、ローカルポリシがTSIGの拒絶を要 求するかもしれません(MAY)。 When a local policy permits acceptance of a TSIG with a particular algorithm and a particular non-zero amount of truncation, it SHOULD also permit the use of that algorithm with lesser truncation (a longer MAC) up to the full HMAC output. ローカルポリシが特定のアルゴリズムのTSIGの受け入れと特定のゼロ 以外の量の切詰めを認めるとき、ローカルポリシはより短い切詰め(より長い MAC)から完全HMAC出力まで使用を認めるべきです(SHOULD)。 Regardless of a lower acceptable truncated MAC length specified by local policy, a reply SHOULD be sent with a MAC at least as long as that in the corresponding request, unless the request specified a MAC length longer than the HMAC output. ローカルポリシによって指定されたより短い許容できる切り落とされた MAC長にかかわらず、要求の指定したMACがHMAC出力より大きくな い限り、応答は対応する要求のMAC以上のMACで送信すべきです(SHOULD)。 Implementations permitting multiple acceptable algorithms and/or truncations SHOULD permit this list to be ordered by presumed strength and SHOULD allow different truncations for the same algorithm to be treated as separate entities in this list. When so implemented, policies SHOULD accept a presumed stronger algorithm and truncation than the minimum strength required by the policy. 多数のアルゴリズムや多数の切詰めを許容する実装は、このリストを強 さの順でならべる事を許すべきで(SHOULD)、同じアルゴリズムの異なった切 り詰めをこのリストで別の項目と扱うことを許すべきです(SHOULD)。これが 実装されるとき、ポリシは、ポリシが要求する最小の強さより強いアルゴリ ズムと切詰めを受け入れるべきです(SHOULD)。 If a TSIG is received with truncation that is permitted under Section 3 above but the MAC is too short for the local policy in force, an RCODE of 22 (BADTRUNC) MUST be returned. もし、上記3章でで認められる切詰めであるが、ローカルポリシで認め るには短いTSIGを受信するならRCODE 22(BADTRUNC)が返されなくては なりません(MUST)。 5. IANA Considerations 5. IANAの考慮 This document (1) registers the new TSIG algorithm identifiers listed in Section 2 with IANA and (2) allocates the BADTRUNC RCODE 22 in Section 4 [RFC2845]. この文書は(1)IANAに2章で示す新しいTSIG識別子を登録し(2)4章で BADTRUNC RCODE 22ます[RFC2845]。 6. Security Considerations 6. セキュリティの考察 For all of the message authentication code algorithms listed herein, those producing longer values are believed to be stronger; however, while there have been some arguments that mild truncation can strengthen a MAC by reducing the information available to an attacker, excessive truncation clearly weakens authentication by reducing the number of bits an attacker has to try to break the authentication by brute force [RFC2104]. 軽い切詰めは攻撃者が利用可能な情報を減らすのでMACを強化するとの 議論はありますが、ここにリストされた全てのメッセージ認証コードアル ゴリズムはより長い値を生成するのがより強いと信じられます、過度の切 詰めは、攻撃者が力ずく攻撃[RFC2104]で破るべきビット数を減らすので、 明らかに認証を弱体化させます。 Significant progress has been made recently in cryptanalysis of hash function of the types used herein, all of which ultimately derive from the design of MD4. While the results so far should not effect HMAC, the stronger SHA-1 and SHA-256 algorithms are being made mandatory due to caution. ここに使われたタイプのハッシュ関数の暗号解読で、究極的にMD4の設 計に依存して、最近著しい進展が成し遂げられました。この結果はこれま でのところHMACに影響は与えいませんが、より強いSHA−1とSH A−256アルゴリズムが注意のために必須化されています。 See the Security Considerations section of [RFC2845]. See also the Security Considerations section of [RFC2104] from which the limits on truncation in this RFC were taken. [RFC2845]のセキュリティの考察章を見てください。同じくこのRFCの切 詰めに対する限度の基になった[RFC2104]のセキュリティの考察章を見てく ださい。 7. Normative References 7. 参照する参考文献 [FIPS180-2] "Secure Hash Standard", (SHA-1/224/256/384/512) US Federal Information Processing Standard, with Change Notice 1, February 2004. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC 1321, April 1992. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001. [RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224", RFC 3874, September 2004. [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA)", RFC 4634, July 2006. [STD13] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. 8. Informative References. 8. 有益な参考文献 [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000. [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000. [RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J., and R. Hall, "Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS- TSIG)", RFC 3645, October 2003. Author's Address 著者のアドレス Donald E. Eastlake 3rd Motorola Laboratories 155 Beaver Street Milford, MA 01757 USA Phone: +1-508-786-7554 (w) EMail: Donald.Eastlake@motorola.com Full Copyright Statement 完全著作権表示 Copyright (C) The Internet Society (2006). 著作権(C)インターネット社会(2006)。 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. この文書はBCP78に含まれる権利と許可と制限の適用を受け、そして この中に明らかにされる以外は著者がすべての権利を維持します。 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文書の権利に関する手続 きの情報はBCP78とBCP79を見てください。 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 provided by the IETF Administrative Support Activity (IASA). RFCエディタ機能のための資金供給が現在インターネット学会によって 供給されます。