RFC4635 日本語訳
4635 HMAC SHA (Hashed Message Authentication Code, Secure HashAlgorithm) TSIG Algorithm Identifiers. D. Eastlake 3rd. August 2006. (Format: TXT=16533 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Eastlake 3rd Request for Comments: 4635 Motorola Laboratories Category: Standards Track August 2006
コメントを求めるワーキンググループのD.イーストレーク第3要求をネットワークでつないでください: 4635年のモトローラ研究所カテゴリ: 標準化過程2006年8月
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).
Copyright(C)インターネット協会(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リソース記録の使用は暗号のメッセージ確認コードの仕様を必要とします。 現在、識別子はHMAC MD5(メッセージ立証コード、Message Digest5を論じ尽くす)とGSS(ジェネリックSecurity Service)TSIGアルゴリズムだけに指定されました。このドキュメントは、追加HMAC SHA(安全なHash Algorithm)TSIGアルゴリズムのために識別子と実装要件を標準化して、TSIGでHMAC値のトランケーションを指定して、どう扱うかを標準化します。
Table of Contents
目次
1. Introduction ....................................................2 2. Algorithms and Identifiers ......................................2 3. Specifying Truncation ...........................................3 3.1. Truncation Specification ...................................4 4. TSIG Truncation Policy and Error Provisions .....................4 5. IANA Considerations .............................................5 6. Security Considerations .........................................5 7. Normative References ............................................6 8. Informative References. .........................................7
1. 序論…2 2. アルゴリズムと識別子…2 3. トランケーションを指定します…3 3.1. トランケーション仕様…4 4. TSIGトランケーション方針と誤り条項…4 5. IANA問題…5 6. セキュリティ問題…5 7. 標準の参照…6 8. 有益な参照。 .........................................7
Eastlake 3rd Standards Track [Page 1] RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006
イーストレーク第3規格はHMAC SHA TSIGアルゴリズム識別子2006年8月にRFC4635を追跡します[1ページ]。
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 Resource Record(RR)を指定します。 このRRは使用される認証アルゴリズムを命名するドメイン名構文データ項目を含んでいます。 [RFC2845]は、認証子のためにMD5(メッセージDigest5)[RFC1321]ハッシュアルゴリズムがあるHMAC(メッセージ立証コードを論じ尽くします)[RFC2104]アルゴリズムを使用することでHMAC-MD5.SIG-ALG.REG.INT名を定義します。 また、IANAはTSIG認証のための暗号の操作がGeneric Security Service(GSS)[RFC3645]へ代表として派遣される識別子として"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(合衆国とScienceのNational InstituteとTechnology、Secure Hash Algorithm)アルゴリズムと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では、このドキュメントは指定されたハッシュ関数の基準出力サイズとTSIG RRで与えられた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"、「必須NOT」“SHOULD"、「」、「5月」であるべきである(中[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 Resource Records(RRs)[RFC2845]は、DNS質問と応答を認証するのに使用されます。 彼らは共有秘密キーに基づく効率的な左右対称の認証子であることを意図します。 SIG RR[RFC2931]を使用することで非対称の署名を提供できます。(特に、トランザクション署名にSIG(0)を使用できます。) 強いハッシュ関数で使用されていて、HMAC[RFC2104]はそのような左右対称の認証子について計算する方法を提供します。 唯一の指定されたHMACベースのTSIGアルゴリズム識別子がMD5に基づいたHMAC-MD5.SIG- ALG.REG.INT[RFC1321]です。
Eastlake 3rd Standards Track [Page 2] RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006
イーストレーク第3規格はHMAC SHA TSIGアルゴリズム識別子2006年8月にRFC4635を追跡します[2ページ]。
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.
SHA-1の使用[FIPS180-2、RFC3174]、およびSHAファミリーにおける224、256がある追加ハッシュアルゴリズム[FIPS180-2、RFC3874、RFC4634]、いくつかの場合、384、および512ビット、好まれるかもしれません。(使用はMD5のための128ビットと比べた160ビットのハッシュです)。 これは、より短いハッシュでますますうまくいっているcryptanalytic攻撃をしているからです。
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の制限とガイドラインを条件として許容できる追加アルゴリズムと評価基準のサポートを含むことができます。 主要な協定がTKEYメカニズム[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 MUSTをサポートする実装も、HMAC SHA1とHMAC SHA256を実装して、gss-tsigを実装するかもしれません、そして、他のアルゴリズムは以下に記載しました。
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
義務的な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.
SHA-1は(12の八重奏)SHOULDに96ビットに先端を切らせました。実装されます。
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 RR[RFC2845]は「MACサイズ」分野を含んでいます。(それは、八重奏における、MAC分野のサイズを与えます)。 しかしながら、このMACサイズが特定のハッシュ関数のためのHMACの出力の長さと異なっているなら、[RFC2845]は、何をしたらよいかを指定しません。 トランケーションは以下で指定されるとしてHMACサイズより少ないMACサイズによって示されます。
Eastlake 3rd Standards Track [Page 3] RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006
イーストレーク第3規格はHMAC SHA TSIGアルゴリズム識別子2006年8月にRFC4635を追跡します[3ページ]。
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.
受け取るなら、本件は、パケットが下げられるのを返して、生成されてはいけなくて、RCODE1(FORMERR)を返さなければなりません。
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.
署名者が許容できる長さにHMAC出力に先端を切らせたとき、これを送ります、RFC2104で説明されて、初期の八重奏を取って、引きずっている八重奏を捨てるとして。 整数の八重奏には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.
あるTSIGを除いて、エラーメッセージが、RFC2845、セクション3.2でMACサイズがゼロであると説明して、受け取るなら、本件は、パケットが下げられるのを返して、生成されてはいけなくて、RCODE1(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
TSIGの使用はレゾルバとサーバの間で相談ずくです。このドキュメントにおける拡大で、そのような「協定」で暗黙であることは、許容できるキーとアルゴリズムに関する評価基準とトランケーションです。 実装がレゾルバとサーバには特定のアルゴリズムには適所にあるかもしれないTSIG秘密鍵かキーを縛るのが、一般的であることに注意してください。その結果、そのような実装は可能にするだけです。
Eastlake 3rd Standards Track [Page 4] RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006
イーストレーク第3規格はHMAC SHA TSIGアルゴリズム識別子2006年8月にRFC4635を追跡します[4ページ]。
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.
そこであるなら、アルゴリズムの使用は適所にある関連キーです。 未知の、または、非実装しているか、障害があるアルゴリズムの領収書はBADKEY誤りを通常もたらします。
Local policies MAY require the rejection of TSIGs, even though they use an algorithm for which implementation is mandatory.
彼らは実装が義務的であるアルゴリズムを使用しますが、ローカルの方針はTSIGsの拒絶を必要とするかもしれません。
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の承認を可能にするか、そして、特定の非ゼロはトランケーションを達させます、それ。また、SHOULDは、より少ないトランケーション(より長いMAC)があるそのアルゴリズムの使用を完全なHMAC出力まで可能にします。
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.
ローカルの方針、回答SHOULDによって指定された下側の許容できる端が欠けているMACの長さにかかわらず、対応する要求におけるそれとしての少なくとも同じくらい長いMACと共に送ってください、要求がHMAC出力より長い間MACの長さを指定しなかったなら。
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を受け取りますが、ローカルの既契約には、MACが短過ぎるなら、22(BADTRUNC)のRCODEを返さなければなりません。
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[RFC2845]にBADTRUNC RCODE22を割り当てます。
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
重要な進歩は最近、ここに使用されるそれのすべてが結局MD4のデザインに由来しているタイプのハッシュ関数の暗号文解読術で見られました。 効果ではなく、そうが遠くにそうするべきである結果をゆったり過ごしてください。
Eastlake 3rd Standards Track [Page 5] RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006
イーストレーク第3規格はHMAC SHA TSIGアルゴリズム識別子2006年8月にRFC4635を追跡します[5ページ]。
HMAC, the stronger SHA-1 and SHA-256 algorithms are being made mandatory due to caution.
HMAC、より強いSHA-1、およびSHA-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]のSecurity Considerations部を見てください。 また、このRFCのトランケーションにおける限界が取られた[RFC2104]のSecurity Considerations部を見てください。
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.
[FIPS180-2]「安全なハッシュ規格」、変更通知1、2004年2月がある(SHA-1/224/256/384/512)米国の連邦情報処理基準。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC 1321, April 1992.
[RFC1321] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845]Vixie(P.、グドムンソン、O.、イーストレーク3番目、D.、およびB.ウェリントン、「DNS(TSIG)のための秘密鍵トランザクション認証」、RFC2845)は2000がそうするかもしれません。
[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174]イーストレーク3番目とD.とP.ジョーンズ、「米国安全なハッシュアルゴリズム1(SHA1)」、RFC3174 2001年9月。
[RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224", RFC 3874, September 2004.
[RFC3874]Housley、R.、「224ビットの一方向ハッシュは機能します」。 "SHA-224"、2004年9月のRFC3874。
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA)", RFC 4634, July 2006.
[RFC4634]イーストレークとD.とT.ハンセン、「米国の安全なハッシュアルゴリズム(SHA)」、RFC4634 2006年7月。
[STD13] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[STD13]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
Eastlake 3rd Standards Track [Page 6] RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006
イーストレーク第3規格はHMAC SHA TSIGアルゴリズム識別子2006年8月にRFC4635を追跡します[6ページ]。
8. Informative References.
8. 有益な参照。
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000.
[RFC2930] イーストレーク3番目、D.、「DNS(TKEY RR)のための秘密鍵設立」、RFC2930、2000年9月。
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000.
2000年の[RFC2931]イーストレークD.、「DNS要求とトランザクション署名(SIG(0)s)」、RFC2931 9月3日。
[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.
[RFC3645] クワン、S.、Garg、P.、ギルロイ、J.、Esibov、L.、Westhead、J.、およびR.ホール、「DNSのための秘密鍵トランザクション認証のためのジェネリックセキュリティー・サービスアルゴリズム(GSS- TSIG)」、RFC3645(2003年10月)。
Author's Address
作者のアドレス
Donald E. Eastlake 3rd Motorola Laboratories 155 Beaver Street Milford, MA 01757 USA
ドナルドE.イーストレーク第3モトローラ研究所155ビーバー通りMA01757ミルフォード(米国)
Phone: +1-508-786-7554 (w) EMail: Donald.Eastlake@motorola.com
以下に電話をしてください。 +1-508-786-7554 (w) メールしてください: Donald.Eastlake@motorola.com
Eastlake 3rd Standards Track [Page 7] RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006
イーストレーク第3規格はHMAC SHA TSIGアルゴリズム識別子2006年8月にRFC4635を追跡します[7ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Eastlake 3rd Standards Track [Page 8]
イーストレーク第3標準化過程[8ページ]
一覧
スポンサーリンク