RFC4757 日本語訳
4757 The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows.K. Jaganathan, L. Zhu, J. Brezak. December 2006. (Format: TXT=36562 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Jaganathan
Request for Comments: 4757 L. Zhu
Category: Informational J. Brezak
Microsoft Corporation
December 2006
Jaganathanがコメントのために要求するワーキンググループK.をネットワークでつないでください: 4757年のL.朱カテゴリ: 情報のJ.Brezakマイクロソフト社2006年12月
The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows
マイクロソフトWindowsによって使用されたRC4-HMACケルベロス暗号化タイプ
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(2006)。
IESG Note
IESG注意
This document documents the RC4 Kerberos encryption types first introduced in Microsoft Windows 2000. Since then, these encryption types have been implemented in a number of Kerberos implementations. The IETF Kerberos community supports publishing this specification as an informational document in order to describe this widely implemented technology. However, while these encryption types provide the operations necessary to implement the base Kerberos specification [RFC4120], they do not provide all the required operations in the Kerberos cryptography framework [RFC3961]. As a result, it is not generally possible to implement potential extensions to Kerberos using these encryption types. The Kerberos encryption type negotiation mechanism [RFC4537] provides one approach for using such extensions even when a Kerberos infrastructure uses long-term RC4 keys. Because this specification does not implement operations required by RFC 3961 and because of security concerns with the use of RC4 and MD4 discussed in Section 8, this specification is not appropriate for publication on the standards track.
このドキュメントは最初にマイクロソフトWindows2000で導入されたRC4ケルベロス暗号化タイプを記録します。 それ以来、これらの暗号化タイプは多くのケルベロス実装で実装されています。 IETFケルベロス共同体は、この広く実装している技術を説明するために情報のドキュメントとして出版がこの仕様であるとサポートします。 しかしながら、これらの暗号化タイプがベースケルベロスが仕様[RFC4120]であると実装するのに必要な操作を提供している間、それらはケルベロス暗号フレームワーク[RFC3961]にすべての必要な操作を提供するというわけではありません。 その結果、一般に、これらの暗号化タイプを使用するケルベロスに潜在的拡大を実装するのは可能ではありません。 ケルベロス暗号化タイプ交渉メカニズム[RFC4537]はケルベロスインフラストラクチャが長期のRC4キーを使用するとそのような拡張子を使用するための1つのアプローチを提供します。 セクション8でRC4とMD4の使用について議論している状態でこの仕様がRFC3961と安全上の配慮のために必要である操作を実装しないので、標準化過程に関する公表には、この仕様は適切ではありません。
Jaganathan, et al. Informational [Page 1] RFC 4757 RC4-HMAC December 2006
Jaganathan、他 [1ページ]情報のRFC4757RC4-HMAC2006年12月
Abstract
要約
The Microsoft Windows 2000 implementation of Kerberos introduces a new encryption type based on the RC4 encryption algorithm and using an MD5 HMAC for checksum. This is offered as an alternative to using the existing DES-based encryption types.
ケルベロスのマイクロソフトWindows2000実装は、RC4暗号化アルゴリズムに基づいていて、チェックサムにMD5 HMACを使用することで新しい暗号化タイプを導入します。 既存のDESベースの暗号化タイプを使用することに代わる手段としてこれを提供します。
The RC4-HMAC encryption types are used to ease upgrade of existing Windows NT environments, provide strong cryptography (128-bit key lengths), and provide exportable (meet United States government export restriction requirements) encryption. This document describes the implementation of those encryption types.
RC4-HMAC暗号化タイプは、既存のWindows NT環境のアップグレードを緩和して、強い暗号(128ビットのキー長)を提供して、輸出向き(合衆国政府輸出限定要求を満たす)の暗号化を提供するのに使用されます。 このドキュメントはそれらの暗号化タイプの実装について説明します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Key Generation ..................................................3
3. Basic Operations ................................................4
4. Checksum Types ..................................................5
5. Encryption Types ................................................6
6. Key Strength Negotiation ........................................8
7. GSS-API Kerberos V5 Mechanism Type ..............................8
7.1. Mechanism Specific Changes .................................8
7.2. GSS-API MIC Semantics ......................................9
7.3. GSS-API WRAP Semantics ....................................11
8. Security Considerations ........................................15
9. IANA Considerations ............................................15
10. Acknowledgements ..............................................15
11. References ....................................................16
11.1. Normative References .....................................16
11.2. Informative References ...................................16
1. 序論…3 1.1. このドキュメントで中古のコンベンション…3 2. 重要世代…3 3. 基本的な操作…4 4. チェックサムタイプ…5 5. 暗号化タイプ…6 6. 主要な強さ交渉…8 7. GSS-APIケルベロスV5メカニズムタイプ…8 7.1. メカニズムの特定の変化…8 7.2. GSS-API MIC意味論…9 7.3. GSS-API包装意味論…11 8. セキュリティ問題…15 9. IANA問題…15 10. 承認…15 11. 参照…16 11.1. 標準の参照…16 11.2. 有益な参照…16
Jaganathan, et al. Informational [Page 2] RFC 4757 RC4-HMAC December 2006
Jaganathan、他 [2ページ]情報のRFC4757RC4-HMAC2006年12月
1. Introduction
1. 序論
The Microsoft Windows 2000 implementation of Kerberos contains new encryption and checksum types for two reasons. First, for export reasons early in the development process, 56-bit DES encryption could not be exported, and, second, upon upgrade from Windows NT 4.0 to Windows 2000, accounts will not have the appropriate DES keying material to do the standard DES encryption. Furthermore, 3DES was not available for export when Windows 2000 was released, and there was a desire to use a single flavor of encryption in the product for both US and international products.
ケルベロスのマイクロソフトWindows2000実装は2つの理由で新しい暗号化とチェックサムタイプを含んでいます。 最初の輸出が早く開発過程で推論するので56ビットのDES暗号化をエクスポートすることができませんでした、そして、2番目に、Windows NT4.0からWindows2000までのアップグレードのときに、アカウントで、適切なDESは標準のDES暗号化をするために材料を合わせないでしょう。 Windows2000がリリースされたとき、その上、3DESは輸出に利用可能ではありませんでした、そして、米国のものと同様に国際的な製品に製品の中の暗号化のただ一つの風味を使用する願望がありました。
As a result, there are two new encryption types and one new checksum type introduced in Microsoft Windows 2000.
その結果、マイクロソフトWindows2000で導入された2つの新しい暗号化タイプと1つの新しいチェックサムタイプがあります。
Note that these cryptosystems aren't intended to be complete, general-purpose Kerberos encryption or checksum systems as defined in [RFC3961]: there is no one-one mapping between the operations in this documents and the primitives described in [RFC3961].
これらの暗号系が[RFC3961]で定義されるように完全で、汎用のケルベロス暗号化かチェックサムシステムであることを意図しないことに注意してください: そこに、1-1がないマッピングが[RFC3961]で説明されたこのドキュメントと基関数に操作の間にありますか?
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように解釈されることであるべきですか?
2. Key Generation
2. キー生成
On upgrade from existing Windows NT domains, the user accounts would not have a DES-based key available to enable the use of DES base encryption types specified in [RFC4120] and [RFC3961]. The key used for RC4-HMAC is the same as the existing Windows NT key (NT Password Hash) for compatibility reasons. Once the account password is changed, the DES-based keys are created and maintained. Once the DES keys are available, DES-based encryption types can be used with Kerberos.
既存のWindows NTドメインからのアップグレードのときに、ユーザアカウントには、[RFC4120]と[RFC3961]で指定されたDESベース暗号化タイプの使用を可能にするために利用可能なDESベースのキーがないでしょう。 RC4-HMACに使用されるキーは互換性のための既存のWindows NTキー(NT Password Hash)が推論するのと同じです。 いったんアカウントパスワードを変えると、DESベースのキーを作成して、維持します。 DESキーがいったん利用可能になると、ケルベロスでDESベースの暗号化タイプを使用できます。
The RC4-HMAC string to key function is defined as follows:
主要な機能へのRC4-HMACストリングは以下の通り定義されます:
String2Key(password)
String2Key(パスワード)
K = MD4(UNICODE(password))
K=MD4(ユニコード(パスワード))
The RC4-HMAC keys are generated by using the Windows UNICODE version of the password. Each Windows UNICODE character is encoded in little-endian format of 2 octets each. Then an MD4 [RFC1320] hash operation is performed on just the UNICODE characters of the password (not including the terminating zero octets).
RC4-HMACキーは、パスワードのWindowsユニコードバージョンを使用することによって、生成されます。 それぞれのWindowsユニコード文字はそれぞれ2つの八重奏のリトルエンディアン形式でコード化されます。 そして、MD4[RFC1320]ハッシュ操作はまさしくパスワードのユニコード文字に実行されます(終わりを含んでいないと、八重奏のゼロは合っています)。
Jaganathan, et al. Informational [Page 3] RFC 4757 RC4-HMAC December 2006
Jaganathan、他 [3ページ]情報のRFC4757RC4-HMAC2006年12月
For an account with a password of "foo", this String2Key("foo") will
return:
"foo"に関するパスワードとのアカウントのために、このString2Key("foo")は戻るでしょう:
0xac, 0x8e, 0x65, 0x7f, 0x83, 0xdf, 0x82, 0xbe,
0xea, 0x5d, 0x43, 0xbd, 0xaf, 0x78, 0x00, 0xcc
0xac、0x8e、0×65、0x7f、0×83、0xdf、0×82、0xbe、0xea、0x5d、0×43、0xbd、0xaf、0×78、0×00、0xcc
3. Basic Operations
3. 基本的な操作
The MD5 HMAC function is defined in [RFC2104]. It is used in this encryption type for checksum operations. Refer to [RFC2104] for details on its operation. In this document, this function is referred to as HMAC(Key, Data) returning the checksum using the specified key on the data.
MD5 HMAC機能は[RFC2104]で定義されます。 それはチェックサム操作にこの暗号化タイプで使用されます。 操作に関する詳細について[RFC2104]を参照してください。 本書では、この機能は、データで指定されたキーを使用することでチェックサムを返しながら、HMAC(キー、Data)と呼ばれます。
The basic MD5 hash operation is used in this encryption type and defined in [RFC1321]. In this document, this function is referred to as MD5(Data) returning the checksum of the data.
基本的なMD5ハッシュ操作は、この暗号化タイプで使用されて、[RFC1321]で定義されます。 本書では、この機能は、データのチェックサムを返しながら、MD5(データ)と呼ばれます。
RC4 is a stream cipher licensed by RSA Data Security. In this document, the function is referred to as RC4(Key, Data) returning the encrypted data using the specified key on the data.
RC4はRSA Data Securityによって認可されたストリーム暗号です。 本書では、機能は、データで指定されたキーを使用することで暗号化されたデータを返しながら、RC4(キー、Data)と呼ばれます。
These encryption types use key derivation. With each message, the message type (T) is used as a component of the keying material. The following table summarizes the different key derivation values used in the various operations. Note that these differ from the key derivations used in other Kerberos encryption types. T = the message type, encoded as a little-endian four-byte integer.
これらの暗号化タイプは主要な派生を使用します。 各メッセージで、メッセージタイプ(T)は合わせることの材料の成分として使用されます。 以下のテーブルは様々な操作に使用される異なった主要な派生値をまとめます。 これらが他のケルベロス暗号化タイプで使用される主要な派生と異なっていることに注意してください。 Tはリトルエンディアンの4バイトの整数としてコード化されたメッセージタイプと等しいです。
1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the
client key (T=1)
2. AS-REP Ticket and TGS-REP Ticket (includes TGS session key or
application session key), encrypted with the service key (T=2)
3. AS-REP encrypted part (includes TGS session key or application
session key), encrypted with the client key (T=8)
4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the TGS
session key (T=4)
5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the TGS
authenticator subkey (T=5)
6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed
with the TGS session key (T=6)
7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes TGS
authenticator subkey), encrypted with the TGS session key T=7)
8. TGS-REP encrypted part (includes application session key),
encrypted with the TGS session key (T=8)
9. TGS-REP encrypted part (includes application session key),
encrypted with the TGS authenticator subkey (T=8)
1. クライアントキー(T=1)2で暗号化されたAS-REQ PA-ENC-TIMESTAMP padataタイムスタンプ。 サービスキー(T=2)3で暗号化されたAS-REP TicketとTGS-REP Ticket(TGSセッションキーかアプリケーションセッションキーを含んでいます)。 AS-REPはクライアントキー(T=8)4で暗号化された部分(TGSセッションキーかアプリケーションセッションキーを含んでいる)を暗号化しました。 TGSセッションキー(T=4)5で暗号化されたTGS-REQ KDC-REQ-BODY AuthorizationData。 TGS固有識別文字サブキー(T=5)6で暗号化されたTGS-REQ KDC-REQ-BODY AuthorizationData。 TGSセッションキーで合わせられたTGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum(T=6。)7 TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator(TGS固有識別文字サブキーを含んでいる)TGSセッションの主要なT=7と共に暗号化されて、 8. TGS-REPはTGSセッションキー(T=8)で暗号化された部分(アプリケーションセッションキーを含んでいる)を暗号化しました。 9. TGS-REPはTGS固有識別文字サブキーで暗号化された部分(アプリケーションセッションキーを含んでいる)を暗号化しました。(T=8)
Jaganathan, et al. Informational [Page 4] RFC 4757 RC4-HMAC December 2006
Jaganathan、他 [4ページ]情報のRFC4757RC4-HMAC2006年12月
10. AP-REQ Authenticator cksum, keyed with the application session
key (T=10)
11. AP-REQ Authenticator (includes application authenticator
subkey), encrypted with the application session key (T=11)
12. AP-REP encrypted part (includes application session subkey),
encrypted with the application session key (T=12)
13. KRB-PRIV encrypted part, encrypted with a key chosen by the
application. Also for data encrypted with GSS Wrap (T=13)
14. KRB-CRED encrypted part, encrypted with a key chosen by the
application (T=14)
15. KRB-SAFE cksum, keyed with a key chosen by the application.
Also for data signed in GSS MIC (T=15)
10. アプリケーションセッションキー(T=10)11で合わせられたAP-REQ Authenticator cksum。 アプリケーションセッションキー(T=11)12で暗号化されたAP-REQ Authenticator(アプリケーション固有識別文字サブキーを含んでいます)。 AP-REPはアプリケーションセッションキー(T=12)13で暗号化された部分(アプリケーションセッションサブキーを含んでいる)を暗号化しました。 KRB-PRIVはキーがアプリケーションで選ばれている状態で暗号化された部分を暗号化しました。 また、GSS Wrap(T=13)14と共に暗号化されたデータのために。 KRB-CREDはキーがアプリケーション(T=14)15時によって選ばれている状態で暗号化された部分を暗号化しました。 キーがアプリケーションで選ばれている状態で合わせられたKRB-SAFE cksum。 GSS MICにサインインするデータのためにも(T=15)
Relative to RFC-1964 key uses:
RFC-1964に比例して、キーは以下を使用します。
T = 0 in the generation of sequence number for the MIC token
T = 0 in the generation of sequence number for the WRAP token
T = 0 in the generation of encrypted data for the WRAPPED token
WRAPPEDトークンのための暗号化されたデータの世代におけるWRAPトークンT=0のための一連番号の世代におけるMICトークンT=0のための一連番号の世代におけるT=0
All strings in this document are ASCII unless otherwise specified. The lengths of ASCII-encoded character strings include the trailing terminator character (0). The concat(a,b,c,...) function will return the logical concatenation (left to right) of the values of the arguments. The nonce(n) function returns a pseudo-random number of "n" octets.
別の方法で指定されない場合、すべてのストリングが本書ではASCIIです。 ASCIIによってコード化された文字列の長さは引きずっているターミネータキャラクタ(0)を含んでいます。 concat(a、b、c)機能は引数の値の論理的な連結(まっすぐになるのが残される)を返すでしょう。 一回だけ(n)機能は「n」八重奏の擬似乱数を返します。
4. Checksum Types
4. チェックサムタイプ
There is one checksum type used in this encryption type. The Kerberos constant for this type is:
この暗号化タイプで使用される1つのチェックサムタイプがあります。 このタイプのためのケルベロス定数は以下の通りです。
#define KERB_CHECKSUM_HMAC_MD5 (-138)
#KERB_CHECKSUM_HMAC_MD5を定義してください。(-138)
The function is defined as follows:
機能は以下の通り定義されます:
K = the Key
T = the message type, encoded as a little-endian four-byte integer
K=Key Tはリトルエンディアンの4バイトの整数としてコード化されたメッセージタイプと等しいです。
CHKSUM(K, T, data)
CHKSUM(K、T、データ)
Ksign = HMAC(K, "signaturekey") //includes zero octet at end
tmp = MD5(concat(T, data))
CHKSUM = HMAC(Ksign, tmp)
Ksign=HMAC(K、"signaturekey")//は終わりtmp=MD5(concat(T、データ))CHKSUM=HMACに八重奏を全く含んでいません。(Ksign、tmp)
Jaganathan, et al. Informational [Page 5] RFC 4757 RC4-HMAC December 2006
Jaganathan、他 [5ページ]情報のRFC4757RC4-HMAC2006年12月
5. Encryption Types
5. 暗号化タイプ
There are two encryption types used in these encryption types. The Kerberos constants for these types are:
これらの暗号化タイプで使用される2つの暗号化タイプがあります。 これらのタイプのためのケルベロス定数は以下の通りです。
#define KERB_ETYPE_RC4_HMAC 23
#define KERB_ETYPE_RC4_HMAC_EXP 24
#定義、KERB_ETYPE_RC4_HMAC23#、はKERB_ETYPE_RC4_HMAC_EXP24を定義します。
The basic encryption function is defined as follows:
基本的な暗号化機能は以下の通り定義されます:
T = the message type, encoded as a little-endian four-byte integer.
Tはリトルエンディアンの4バイトの整数としてコード化されたメッセージタイプと等しいです。
OCTET L40[14] = "fortybits";
八重奏L40[14]は"fortybits"と等しいです。
The header field on the encrypted data in KDC messages is:
KDCメッセージの暗号化されたデータのヘッダーフィールドは以下の通りです。
typedef struct _RC4_MDx_HEADER {
OCTET Checksum[16];
OCTET Confounder[8];
} RC4_MDx_HEADER, *PRC4_MDx_HEADER;
typedef struct_RC4_MDx_HEADER OCTET Checksum[16]; OCTET Confounder[8];RC4_MDx_HEADER、*PRC4_MDx_HEADER。
ENCRYPT (K, export, T, data)
{
struct EDATA {
struct HEADER {
OCTET Checksum[16];
OCTET Confounder[8];
} Header;
OCTET Data[0];
} edata;
ENCRYPT(K、輸出、T、データ)、struct EDATA struct HEADER OCTET Checksum[16]; OCTET Confounder[8];ヘッダー; OCTET Data[0];edata。
if (export){
*((DWORD *)(L40+10)) = T;
K1 = HMAC(K, L40); // where the length of L40 in
// octets is 14
}
else
{
K1 = HMAC(K, &T); // where the length of T in octets
// is 4
}
memcpy (K2, K1, 16);
if (export) memset (K1+7, 0xAB, 9);
ほかに、{K1はHMAC(K&T)と等しいです; 八重奏//のTの長さが4である//}という*(DWORD*)(L40+10)=T; K1=HMAC(K、L40); //八重奏における、L40の長さが14である(輸出)//であるならmemcpy(K1、16歳のケーツー)。 (輸出)memset(K1+7、0xAB、9)であるなら。
nonce (edata.Confounder, 8);
memcpy (edata.Data, data);
一回だけ(edata.Confounder、8)。 memcpy(edata.Data、データ)。
Jaganathan, et al. Informational [Page 6] RFC 4757 RC4-HMAC December 2006
Jaganathan、他 [6ページ]情報のRFC4757RC4-HMAC2006年12月
edata.Checksum = HMAC (K2, edata);
K3 = HMAC (K1, edata.Checksum);
edata.ChecksumはHMAC(ケーツー、edata)と等しいです。 K3はHMAC(K1、edata.Checksum)と等しいです。
RC4 (K3, edata.Confounder);
RC4 (K3, data.Data);
}
RC4(K3、edata.Confounder)。 RC4(K3、data.Data)。 }
DECRYPT (K, export, T, edata)
{
// edata looks like
struct EDATA {
struct HEADER {
OCTET Checksum[16];
OCTET Confounder[8];
} Header;
OCTET Data[0];
} edata;
DECRYPT(K、輸出、T、edata)、//edataは同様のstruct EDATA struct HEADER OCTET Checksum[16]; OCTET Confounder[8];ヘッダー; OCTET Data[0];edataに見えます。
if (export){
*((DWORD *)(L40+10)) = T;
HMAC (K, L40, 14, K1);
}
else
{
HMAC (K, &T, 4, K1);
}
memcpy (K2, K1, 16);
if (export) memset (K1+7, 0xAB, 9);
ほかの(輸出)*(DWORD*)(L40+10)=T(HMAC(K、L40、14、K1))である、HMAC(K&T、4、K1);、memcpy(K1、16歳のケーツー)。 (輸出)memset(K1+7、0xAB、9)であるなら。
K3 = HMAC (K1, edata.Checksum);
RC4 (K3, edata.Confounder);
RC4 (K3, edata.Data);
K3はHMAC(K1、edata.Checksum)と等しいです。 RC4(K3、edata.Confounder)。 RC4(K3、edata.Data)。
// verify generated and received checksums
checksum = HMAC (K2, concat(edata.Confounder, edata.Data));
if (checksum != edata.Checksum)
printf("CHECKSUM ERROR !!!!!!\n");
}
/が確かめる/は、チェックサムチェックサム=HMAC(ケーツー、concat(edata.Confounder、edata.Data))を生成して、受けました。 (チェックサム!=edata.Checksum)printf(「チェックサム誤り!\n」)であるなら。 }
The KDC message is encrypted using the ENCRYPT function not including the Checksum in the RC4_MDx_HEADER.
KDCメッセージは、RC4_MDx_HEADERにChecksumを含まないENCRYPT機能を使用することで暗号化されています。
The character constant "fortybits" evolved from the time when a 40-bit key length was all that was exportable from the United States. It is now used to recognize that the key length is of "exportable" length. In this description, the key size is actually 56 bits.
40ビットのキー長がそのすべてであった時から発展された文字定数"fortybits"は合衆国から輸出向きでした。 それは、現在、キー長が「輸出向き」の長さのものであると認めるのに使用されます。 この記述では、主要なサイズは実際に56ビットです。
Jaganathan, et al. Informational [Page 7] RFC 4757 RC4-HMAC December 2006
Jaganathan、他 [7ページ]情報のRFC4757RC4-HMAC2006年12月
The pseudo-random operation [RFC3961] for both enctypes above is defined as follows:
上の両方のenctypesのための擬似ランダム操作[RFC3961]は以下の通り定義されます:
pseudo-random(K, S) = HMAC-SHA1(K, S)
擬似ランダム(K、S)=HMAC-SHA1(K、S)
where K is the protocol key and S is the input octet string. HMAC-SHA1 is defined in [RFC2104] and the output of HMAC-SHA1 is the 20-octet digest.
KがどこのプロトコルキーとSであるかは入力八重奏ストリングです。 HMAC-SHA1は[RFC2104]で定義されます、そして、HMAC-SHA1の出力は20八重奏のダイジェストです。
6. Key Strength Negotiation
6. 主要な強さ交渉
A Kerberos client and server can negotiate over key length if they are using mutual authentication. If the client is unable to perform full-strength encryption, it may propose a key in the "subkey" field of the authenticator, using a weaker encryption type. The server must then either return the same key or suggest its own key in the subkey field of the AP reply message. The key used to encrypt data is derived from the key returned by the server. If the client is able to perform strong encryption but the server is not, it may propose a subkey in the AP reply without first being sent a subkey in the authenticator.
彼らが互いの認証を使用しているなら、ケルベロスクライアントとサーバはキー長を交渉できます。 クライアントが定員暗号化を実行できないなら、固有識別文字の「サブキー」分野でキーを提案するかもしれません、より弱い暗号化タイプを使用して。 そして、サーバは、AP応答メッセージのサブキー分野に同じキーを返さなければならないか、またはそれ自身のキーを示さなければなりません。 サーバによって返されたキーからデータを暗号化するのに使用されるキーを得ます。最初に固有識別文字でサブキーを送らないで、クライアントが強い暗号化を実行できますが、サーバが実行するというわけではないなら、それはAP回答でサブキーを提案するかもしれません。
7. GSS-API Kerberos V5 Mechanism Type
7. GSS-APIケルベロスV5メカニズムタイプ
7.1. Mechanism Specific Changes
7.1. メカニズムの特定の変化
The Generic Security Service Application Program Interface (GSS-API) per-message tokens also require new checksum and encryption types. The GSS-API per-message tokens are adapted to support these new encryption types. See [RFC1964] Section 1.2.2.
また、1メッセージあたりのGeneric Security Service Application Program Interface(GSS-API)トークンは新しいチェックサムと暗号化タイプを必要とします。 1メッセージあたりのGSS-APIトークンは、これらが新しい暗号化タイプであるとサポートするために適合させられます。 [RFC1964]セクション1.2.2を見てください。
The only support quality of protection is:
保護の唯一のサポート品質は以下の通りです。
#define GSS_KRB5_INTEG_C_QOP_DEFAULT 0x0
#GSS_KRB5_INTEG_C_QOP_DEFAULT0x0を定義してください。
When using this RC4-based encryption type, the sequence number is always sent in big-endian rather than little-endian order.
このRC4ベースの暗号化タイプを使用するとき、リトルエンディアンオーダーよりむしろビッグエンディアンで一連番号をいつも送ります。
The Windows 2000 implementation also defines new GSS-API flags in the initial token passed when initializing a security context. These flags are passed in the checksum field of the authenticator. See [RFC1964] Section 1.1.1.
また、Windows2000実装はセキュリティ文脈を初期化するとき通過された初期のトークンで新しいGSS-API旗を定義します。 これらの旗は固有識別文字のチェックサム分野で渡されます。 [RFC1964]セクション1.1.1を見てください。
GSS_C_DCE_STYLE - This flag was added for use with Microsoft's implementation of Distributed Computing Environment Remote Procedure Call (DCE RPC), which initially expected three legs of authentication. Setting this flag causes an extra AP reply to be sent from the client back to the server after receiving the server's
GSS_C_DCE_様式--この旗は使用のためにマイクロソフトのDistributed Computing Environment Remote Procedure Call(DCE RPC)の実装で加えられました。(Distributed Computing Environment Remote Procedure Callは初めは、認証の3つの行程を予想しました)。 この旗を設定するのに、サーバを受け取った後に、付加的なAP回答をクライアントからサーバに送って戻します。
Jaganathan, et al. Informational [Page 8] RFC 4757 RC4-HMAC December 2006
Jaganathan、他 [8ページ]情報のRFC4757RC4-HMAC2006年12月
AP reply. In addition, the context negotiation tokens do not have GSS-API per-message tokens -- they are raw AP messages that do not include object identifiers.
APは返答します。 さらに、文脈交渉トークンには、1メッセージあたりのGSS-APIトークンがありません--それらはオブジェクト識別子を含んでいない生のAPメッセージです。
#define GSS_C_DCE_STYLE 0x1000
#GSS_C_DCE_様式0x1000を定義してください。
GSS_C_IDENTIFY_FLAG - This flag allows the client to indicate to the server that it should only allow the server application to identify the client by name and ID, but not to impersonate the client.
GSS_C_IDENTIFY_FLAG--この旗で、クライアントは、サーバ・アプリケーションがクライアントをまねるのではなく、名前とIDでクライアントを特定できるだけであるべきであるのをそれでサーバに示すことができます。
#define GSS_C_IDENTIFY_FLAG 0x2000
#GSS_C_IDENTIFY_FLAG0x2000を定義してください。
GSS_C_EXTENDED_ERROR_FLAG - Setting this flag indicates that the client wants to be informed of extended error information. In particular, Windows 2000 status codes may be returned in the data field of a Kerberos error message. This allows the client to understand a server failure more precisely. In addition, the server may return errors to the client that are normally handled at the application layer in the server, in order to let the client try to recover. After receiving an error message, the client may attempt to resubmit an AP request.
GSS_C_EXTENDED_ERROR_FLAG--この旗を設定するのは、クライアントが拡張エラー情報で知識があるようになりたいのを示します。 特に、ケルベロスエラーメッセージのデータ・フィールドでWindows2000ステータスコードを返すかもしれません。 これで、クライアントは、より正確にサーバ失敗を理解できます。 さらに、サーバはクライアントへの通常、応用層でサーバで扱われる誤りを返すかもしれません、クライアントが回復しようとするのをさせるために。エラーメッセージを受け取った後に、クライアントは、AP要求を再提出するのを試みるかもしれません。
#define GSS_C_EXTENDED_ERROR_FLAG 0x4000
#GSS_C_EXTENDED_ERROR_FLAG0x4000を定義してください。
These flags are only used if a client is aware of these conventions when using the Security Support Provider Interface (SSPI) on the Windows platform; they are not generally used by default.
WindowsプラットホームのSecurity Support Provider Interface(SSPI)を使用するとき、クライアントがこれらのコンベンションを意識している場合にだけ、これらの旗は使用されます。 一般に、それらはデフォルトで使用されません。
When NetBIOS addresses are used in the GSS-API, they are identified by the GSS_C_AF_NETBIOS value. This value is defined as:
NetBIOSアドレスがGSS-APIで使用されるとき、彼らはGSS_C_AF_NETBIOS価値によって特定されます。 この値は以下と定義されます。
#define GSS_C_AF_NETBIOS 0x14
#GSS_C_AF_NETBIOS0x14を定義してください。
NetBios addresses are 16-octet addresses typically composed of 1 to 15 characters, trailing blank (ASCII char 20) filled, with a 16th octet of 0x0.
NetBiosアドレスは1〜15のキャラクタで通常構成された、16八重奏のアドレスです、(ASCII炭20)がいっぱいになった引きずっている空白、0×0の16番目の八重奏で。
7.2. GSS-API MIC Semantics
7.2. GSS-API MIC意味論
The GSS-API checksum type and algorithm are defined in Section 5. Only the first 8 octets of the checksum are used. The resulting checksum is stored in the SGN_CKSUM field. See [RFC1964] Section 1.2 for GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE).
GSS-APIチェックサムタイプとアルゴリズムはセクション5で定義されます。 チェックサムの最初の8つの八重奏だけが使用されています。 結果として起こるチェックサムはSGN_CKSUM分野に保存されます。 GetMIC()とGSS_が包装するGSS_に関して[RFC1964]セクション1.2を見てください(conf_は= 虚偽で弛みます)。
Jaganathan, et al. Informational [Page 9] RFC 4757 RC4-HMAC December 2006
Jaganathan、他 [9ページ]情報のRFC4757RC4-HMAC2006年12月
The GSS_GetMIC token has the following format:
GSS_GetMICトークンには、以下の形式があります:
Byte no Name Description
0..1 TOK_ID Identification field.
Tokens emitted by GSS_GetMIC() contain
the hex value 01 01 in this field.
2..3 SGN_ALG Integrity algorithm indicator.
11 00 - HMAC
4..7 Filler Contains ff ff ff ff
8..15 SND_SEQ Sequence number field.
16..23 SGN_CKSUM Checksum of "to-be-signed data",
calculated according to algorithm
specified in SGN_ALG field.
バイトはName記述ではありません0。1 ID IdentificationがさばくTOK_。 GSS_GetMIC()によって放たれたトークンはこの分野に十六進法値01 01を保管しています。 2..3SGN_ALG Integrityアルゴリズムインディケータ。 11 00--HMAC4。7 フィラーContains ff ff ff ff8。15 SND_SEQ Sequenceナンバーフィールド。 16..23 ALGがさばくSGN_で指定されたアルゴリズムによると、計算された「署名しているデータ」のSGN_CKSUM Checksum。
The MIC mechanism used for GSS-MIC-based messages is as follows:
GSS-MICベースのメッセージに使用されるMICメカニズムは以下の通りです:
GetMIC(Kss, direction, export, seq_num, data)
{
struct Token {
struct Header {
OCTET TOK_ID[2];
OCTET SGN_ALG[2];
OCTET Filler[4];
};
OCTET SND_SEQ[8];
OCTET SGN_CKSUM[8];
} Token;
GetMIC(Kss(方向)はエクスポートします、seq_num、データ)、struct Token、struct Header、OCTET TOK_ID[2]; OCTET SGN_ALG[2]; OCTET Filler[4];; OCTET SND_SEQ[8]; OCTET SGN_CKSUM[8];、トークン。
Token.TOK_ID = 01 01;
Token.SGN_SLG = 11 00;
Token.Filler = ff ff ff ff;
Token.TOK_IDは01 01と等しいです。 Token.SGN_SLGは11 00と等しいです。 Token.Fillerはff ff ff ffと等しいです。
// Create the sequence number
//は一連番号を作成します。
if (direction == sender_is_initiator)
{
memset(Token.SEND_SEQ+4, 0xff, 4)
}
else if (direction == sender_is_acceptor)
{
memset(Token.SEND_SEQ+4, 0, 4)
}
Token.SEND_SEQ[0] = (seq_num & 0xff000000) >> 24;
Token.SEND_SEQ[1] = (seq_num & 0x00ff0000) >> 16;
Token.SEND_SEQ[2] = (seq_num & 0x0000ff00) >> 8;
Token.SEND_SEQ[3] = (seq_num & 0x000000ff);
ほかの(方向=送付者_は_創始者です)memset(Token.SEND_SEQ+4、0xff、4)が(方向=送付者_は_アクセプタです)memset(Token.SEND_SEQ+4、0、4)Token.SEND_SEQ[0]であるなら>>24と等しいなら(seq_numと0xff000000)。 Token.SEND_SEQ[1]は>>16と等しいです(seq_numと0x00ff0000)。 Token.SEND_SEQ[2]は>>8と等しいです(seq_numと0x0000ff00)。 Token.SEND_SEQ[3]は(seq_numと0x000000ff)と等しいです。
Jaganathan, et al. Informational [Page 10] RFC 4757 RC4-HMAC December 2006
Jaganathan、他 [10ページ]情報のRFC4757RC4-HMAC2006年12月
// Derive signing key from session key
//はセッションキーから主要な署名を引き出します。
Ksign = HMAC(Kss, "signaturekey");
// length includes terminating null
KsignはHMAC(Kss、"signaturekey")と等しいです。 //長さは、ヌルを終えるのを含んでいます。
// Generate checksum of message - SGN_CKSUM
// Key derivation salt = 15
/がメッセージのチェックサムを生成する/--SGN_CKSUM//主要な派生塩=15
Sgn_Cksum = MD5((int32)15, Token.Header, data);
Sgn_CksumはMD5((int32)15、Token.Header、データ)と等しいです。
// Save first 8 octets of HMAC Sgn_Cksum
//はHMAC Sgn_Cksumの最初の8つの八重奏を保存します。
Sgn_Cksum = HMAC(Ksign, Sgn_Cksum);
memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8);
Sgn_CksumはHMAC(Ksign、Sgn_Cksum)と等しいです。 memcpy(Token.SGN_CKSUM、Sgn_Cksum、8)。
// Encrypt the sequence number
//は一連番号を暗号化します。
// Derive encryption key for the sequence number
// Key derivation salt = 0
//は一連番号//主要な派生塩=0に、主要な暗号化を引き出します。
if (exportable)
{
Kseq = HMAC(Kss, "fortybits", (int32)0);
// len includes terminating null
memset(Kseq+7, 0xab, 7)
}
else
{
Kseq = HMAC(Kss, (int32)0);
}
Kseq = HMAC(Kseq, Token.SGN_CKSUM);
ほかに{KseqはHMAC(Kss、「fortybits」(int32)0)と等しいです; ヌルmemset(Kseq+7、0xab、7)を終える//lenインクルード。}(輸出向き)であるならKseq=HMAC(Kss、(int32)0); KseqはHMAC(Kseq、Token.SGN_CKSUM)と等しいです。
// Encrypt the sequence number
//は一連番号を暗号化します。
RC4(Kseq, Token.SND_SEQ);
}
RC4(Kseq、Token.SND_SEQ)。 }
7.3. GSS-API WRAP Semantics
7.3. GSS-API包装意味論
There are two encryption keys for GSS-API message tokens, one that is 128 bits in strength and one that is 56 bits in strength as defined in Section 6.
2個の暗号化キーがGSS-APIメッセージトークン(セクション6で定義されるように強さにおいて56ビットである強さとものの128ビットであるもの)のためにあります。
All padding is rounded up to 1 byte. One byte is needed to say that there is 1 byte of padding. The DES-based mechanism type uses 8-byte padding. See [RFC1964] Section 1.2.2.3.
すべての詰め物が1バイトまで一周します。 1バイトが、1バイトの詰め物があると言うのに必要です。 DESベースのメカニズムタイプは8バイトの詰め物を使用します。 .3に[RFC1964]セクション1.2.2を見てください。
Jaganathan, et al. Informational [Page 11] RFC 4757 RC4-HMAC December 2006
Jaganathan、他 [11ページ]情報のRFC4757RC4-HMAC2006年12月
The RC4-HMAC GSS_Wrap() token has the following format:
RC4-HMAC GSS_Wrap()トークンには、以下の形式があります:
Byte no Name Description
0..1 TOK_ID Identification field.
Tokens emitted by GSS_Wrap() contain
the hex value 02 01 in this field.
2..3 SGN_ALG Checksum algorithm indicator.
11 00 - HMAC
4..5 SEAL_ALG ff ff - none
00 00 - DES-CBC
10 00 - RC4
6..7 Filler Contains ff ff
8..15 SND_SEQ Encrypted sequence number field.
16..23 SGN_CKSUM Checksum of plaintext padded data,
calculated according to algorithm
specified in SGN_ALG field.
24..31 Confounder Random confounder.
32..last Data Encrypted or plaintext padded data.
バイトはName記述ではありません0。1 ID IdentificationがさばくTOK_。 GSS_Wrap()によって放たれたトークンはこの分野に十六進法値02 01を保管しています。 2..3SGN_ALG Checksumアルゴリズムインディケータ。 11 00--HMAC4。5 SEAL_ALG ff ff--なにも、00 00--DES-CBC10 00--RC4 6。7 フィラーContains ff ff8。15SND_SEQ Encrypted一連番号分野。 16..23 平文のSGN_CKSUM ChecksumはALGがさばくSGN_で指定されたアルゴリズムによると、計算されたデータを水増ししました。 24..31交絡因子Random交絡因子。 32..最後のData Encryptedか平文がデータを水増ししました。
The encryption mechanism used for GSS-wrap-based messages is as follows:
GSS包装ベースのメッセージに使用される暗号化メカニズムは以下の通りです:
WRAP(Kss, encrypt, direction, export, seq_num, data)
{
struct Token { // 32 octets
struct Header {
OCTET TOK_ID[2];
OCTET SGN_ALG[2];
OCTET SEAL_ALG[2];
OCTET Filler[2];
};
OCTET SND_SEQ[8];
OCTET SGN_CKSUM[8];
OCTET Confounder[8];
} Token;
WRAP、(Kss、暗号化、方向、輸出、seq_num、データ)、struct Token//32八重奏struct Header OCTET TOK_ID[2]; OCTET SGN_ALG[2]; OCTET SEAL_ALG[2]; OCTET Filler[2];; OCTET SND_SEQ[8];OCTET SGN_CKSUM[8]; OCTET Confounder[8];トークン。
Token.TOK_ID = 02 01;
Token.SGN_SLG = 11 00;
Token.SEAL_ALG = (no_encrypt)? ff ff : 10 00;
Token.Filler = ff ff;
Token.TOK_IDは02 01と等しいです。 Token.SGN_SLGは11 00と等しいです。 Token.SEAL_ALG=(いいえ_が暗号化する)?ff ff: 10 00; Token.Fillerはff ffと等しいです。
// Create the sequence number
//は一連番号を作成します。
if (direction == sender_is_initiator)
{
(指示=送付者_は_創始者です)
Jaganathan, et al. Informational [Page 12] RFC 4757 RC4-HMAC December 2006
Jaganathan、他 [12ページ]情報のRFC4757RC4-HMAC2006年12月
memset(&Token.SEND_SEQ[4], 0xff, 4)
}
else if (direction == sender_is_acceptor)
{
memset(&Token.SEND_SEQ[4], 0, 4)
}
Token.SEND_SEQ[0] = (seq_num & 0xff000000) >> 24;
Token.SEND_SEQ[1] = (seq_num & 0x00ff0000) >> 16;
Token.SEND_SEQ[2] = (seq_num & 0x0000ff00) >> 8;
Token.SEND_SEQ[3] = (seq_num & 0x000000ff);
memset、(Token.SEND_SEQ[4]、0xff、4)、ほか、(指示=送付者_は_アクセプタです)、memset、(Token.SEND_SEQ[4]、0、4) Token.SEND_SEQ[0]は>>24と等しいです(seq_numと0xff000000)。 Token.SEND_SEQ[1]は>>16と等しいです(seq_numと0x00ff0000)。 Token.SEND_SEQ[2]は>>8と等しいです(seq_numと0x0000ff00)。 Token.SEND_SEQ[3]は(seq_numと0x000000ff)と等しいです。
// Generate random confounder
//は無作為の交絡因子を発生させます。
nonce(&Token.Confounder, 8);
一回だけ(Token.Confounder、8)。
// Derive signing key from session key
//はセッションキーから主要な調印を引き出します。
Ksign = HMAC(Kss, "signaturekey");
KsignはHMAC(Kss、"signaturekey")と等しいです。
// Generate checksum of message -
// SGN_CKSUM + Token.Confounder
// Key derivation salt = 15
//はメッセージのチェックサムを発生させます--//SGN_CKSUM+Token.Confounder//主要な派生塩は15と等しいです。
Sgn_Cksum = MD5((int32)15, Token.Header,
Token.Confounder);
Sgn_CksumはMD5((int32)15、Token.Header、Token.Confounder)と等しいです。
// Derive encryption key for data
// Key derivation salt = 0
//はデータ//主要な派生塩=0に、主要な暗号化を引き出します。
for (i = 0; i < 16; i++) Klocal[i] = Kss[i] ^ 0xF0;
// XOR
if (exportable)
{
Kcrypt = HMAC(Klocal, "fortybits", (int32)0);
// len includes terminating null
memset(Kcrypt+7, 0xab, 7);
}
else
{
Kcrypt = HMAC(Klocal, (int32)0);
}
(i=0; i<16; i++)に関しては、Klocal[i]はKss[i]^0xF0と等しいです。 //XOR、ほかの(輸出向きの)Kcrypt=HMAC(Klocal、"fortybits"(int32)0)(ヌルmemset(Kcrypt+7、0xab、7)を終える//lenインクルード)です。Kcrypt=HMAC(Klocal、(int32)0)。
// new encryption key salted with seq
seqで塩味を付けられた//新しい暗号化キー
Kcrypt = HMAC(Kcrypt, (int32)seq);
KcryptはHMAC(Kcrypt、(int32)seq)と等しいです。
Jaganathan, et al. Informational [Page 13] RFC 4757 RC4-HMAC December 2006
Jaganathan、他 [13ページ]情報のRFC4757RC4-HMAC2006年12月
// Encrypt confounder (if encrypting)
//は交絡因子をコード化します。(コード化するなら)
if (encrypt)
RC4(Kcrypt, Token.Confounder);
(コード化します)RC4(Kcrypt、Token.Confounder)であるなら。
// Sum the data buffer
データがバッファリングする//合計
Sgn_Cksum += MD5(data); // Append to checksum
Sgn_Cksum+=MD5(データ)。 /がチェックサムに追加する/
// Encrypt the data (if encrypting)
//はデータをコード化します。(コード化するなら)
if (encrypt)
RC4(Kcrypt, data);
(コード化します)RC4(Kcrypt、データ)であるなら。
// Save first 8 octets of HMAC Sgn_Cksum
//はHMAC Sgn_Cksumの最初の8つの八重奏を救います。
Sgn_Cksum = HMAC(Ksign, Sgn_Cksum);
memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8);
Sgn_CksumはHMAC(Ksign、Sgn_Cksum)と等しいです。 memcpy(Token.SGN_CKSUM、Sgn_Cksum、8)。
// Derive encryption key for the sequence number
// Key derivation salt = 0
//は一連番号//主要な派生塩=0に、主要な暗号化を引き出します。
if (exportable)
{
Kseq = HMAC(Kss, "fortybits", (int32)0);
// len includes terminating null
memset(Kseq+7, 0xab, 7)
}
else
{
Kseq = HMAC(Kss, (int32)0);
}
Kseq = HMAC(Kseq, Token.SGN_CKSUM);
ほかに{KseqはHMAC(Kss、「fortybits」(int32)0)と等しいです; ヌルmemset(Kseq+7、0xab、7)を終える//lenインクルード。}(輸出向き)であるならKseq=HMAC(Kss、(int32)0); KseqはHMAC(Kseq、Token.SGN_CKSUM)と等しいです。
// Encrypt the sequence number
//は一連番号をコード化します。
RC4(Kseq, Token.SND_SEQ);
RC4(Kseq、Token.SND_SEQ)。
// Encrypted message = Token + Data
}
//暗号化メッセージは象徴+データと等しいです。
The character constant "fortybits" evolved from the time when a 40-bit key length was all that was exportable from the United States. It is now used to recognize that the key length is of "exportable" length. In this description, the key size is actually 56 bits.
40ビットのキー長がそのすべてであった時から発展された文字定数"fortybits"は合衆国から輸出向きでした。 それは、現在、キー長が「輸出向き」の長さのものであると認めるのに使用されます。 この記述では、主要なサイズは実際に56ビットです。
Jaganathan, et al. Informational [Page 14] RFC 4757 RC4-HMAC December 2006
Jaganathan、他 [14ページ]情報のRFC4757RC4-HMAC2006年12月
8. Security Considerations
8. セキュリティ問題
Care must be taken in implementing these encryption types because they use a stream cipher. If a different IV is not used in each direction when using a session key, the encryption is weak. By using the sequence number as an IV, this is avoided.
彼らがストリーム暗号を使用するのでこれらの暗号化タイプを実行しながら、注意を中に入れなければなりません。 セッションキーを使用するとき、異なったIVが各方向に使用されていないなら、暗号化は弱いです。 IVとして一連番号を使用することによって、これは避けられます。
There are two classes of attack on RC4 described in [MIRONOV]. Strong distinguishers distinguish an RC4 keystream from randomness at the start of the stream. Weak distinguishers can operate on any part of the keystream, and the best ones, described in [FMcG] and [MANTIN05], can exploit data from multiple, different keystreams. A consequence of these is that encrypting the same data (for instance, a password) sufficiently many times in separate RC4 keystreams can be sufficient to leak information to an adversary. The encryption types defined in this document defend against these by constructing a new keystream for every message. However, it is RECOMMENDED not to use the RC4 encryption types defined in this document for high-volume connections.
攻撃の2つのクラスが[ミロノフ]で説明されたRC4にあります。 強いdistinguishersは流れの始めで偶発性とRC4 keystreamを区別します。 弱いdistinguishersはkeystreamのどんな部分も作動させることができます、そして、[FMcG]と[MANTIN05]で説明される中で最も良い人は複数の、そして、異なったkeystreamsからのデータを利用できます。これらの結果は別々のRC4 keystreamsで十分何回も同じデータ(例えば、パスワード)をコード化するのが敵に情報を漏らすことができる場合があるくらいのことです。 本書では定義された暗号化タイプは、あらゆるメッセージのために新しいkeystreamを組み立てることによって、これらに対して防御します。 しかしながら、それは本書では大容量接続のために定義されたRC4暗号化タイプを使用しないRECOMMENDEDです。
Weaknesses in MD4 [BOER91] were demonstrated by den Boer and Bosselaers in 1991. In August 2004, Xiaoyun Wang, et al., reported MD4 collisions generated using hand calculation [WANG04]. Implementations based on Wang's algorithm can find collisions in real time. However, the intended usage of MD4 described in this document does not rely on the collision-resistant property of MD4. Furthermore, MD4 is always used in the context of a keyed hash in this document. Although no evidence has suggested keyed MD4 hashes are vulnerable to collision-based attacks, no study has directly proved that the HMAC-MD4 is secure: the existing study simply assumed that the hash function used in HMAC is collision proof. It is thus RECOMMENDED not to use the RC4 encryption types defined in this document if alternative stronger encryption types, such as aes256-cts-hmac-sha1-96 [RFC3962], are available.
MD4[BOER91]の弱点は1991年に穴のボーア人とBosselaersによって示されました。 2004年8月に、Xiaoyunワング(他)は手の計算[WANG04]を使用することで発生するMD4衝突を報告しました。 ワングのアルゴリズムに基づく実現はリアルタイムで、衝突に当たることができます。 しかしながら、本書では説明されたMD4の意図している使用法はMD4の耐衝突の特性を当てにしません。 その上、MD4は合わせられた細切れ肉料理の文脈でいつも本書では使用されます。 どんな証拠も、合わせられたMD4が論じ尽くすのを示していない、衝突ベースの攻撃に傷つきやすいです、どんな研究もHMAC-MD4が以下を安全にすることであると直接立証していないということです。 既存の研究は、HMACで使用されるハッシュ関数が衝突証拠であると単に仮定しました。 その結果、それはaes256-cts-hmac-sha1-96などの代替の、より強い暗号化タイプ[RFC3962]が本書では手があくなら定義されたRC4暗号化タイプを使用しないRECOMMENDEDです。
9. IANA Considerations
9. IANA問題
Section 5 of this document defines two Kerberos encryption types rc4-hmac (23) and rc4-hmac-exp (24). The Kerberos parameters registration page at <http://www.iana.org/assignments/kerberos- parameters> has been updated to reference this document for these two encryption types.
このドキュメントのセクション5は2つのケルベロス暗号化タイプrc4-hmac(23)とrc4-hmac-exp(24)を定義します。 これらの2つの暗号化タイプのために<http://www.iana.org/課題/kerberosパラメタ>のケルベロスパラメタ登録ページをこれが記録する参照にアップデートしました。
10. Acknowledgements
10. 承認
The authors wish to thank Sam Hartman, Ken Raeburn, and Qunli Li for their insightful comments.
作者は彼らの洞察に満ちたコメントについてサム・ハートマン、ケン・レイバーン、およびQunli李に感謝したがっています。
Jaganathan, et al. Informational [Page 15] RFC 4757 RC4-HMAC December 2006
Jaganathan、他 [15ページ]情報のRFC4757RC4-HMAC2006年12月
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[RFC1320] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320,
April 1992.
[RFC1320] Rivest、R.、「MD4メッセージダイジェストアルゴリズム」、RFC1320、1992年4月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1321] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, June 1996.
[RFC1964] リン、J.、「ケルベロスバージョン5GSS-APIメカニズム」、RFC1964、1996年6月。
[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月。
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, February 2005.
[RFC3961] レイバーンとK.と「暗号化とケルベロス5インチチェックサム仕様、RFC3961、2005年2月。」
[RFC3962] Raeburn, K., "Advanced Encryption Standard (AES)
Encryption for Kerberos 5", RFC 3962, February 2005.
[RFC3962]レイバーン(K.)は「2005年2月にケルベロス5インチ、RFC3962のために暗号化の標準の(AES)暗号化を進めました」。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[RFC4120]ヌーマン、C.、ユー、T.、ハートマン、S.、およびK.レイバーン、「ケルベロスネットワーク認証サービス(V5)」、RFC4120 2005年7月。
[RFC4537] Zhu, L., Leach, P., and K. Jaganathan, "Kerberos
Cryptosystem Negotiation Extension", RFC 4537, June 2006.
[RFC4537] 朱とL.とリーチ、P.とK.Jaganathan、「ケルベロス暗号系交渉拡大」、RFC4537、2006年6月。
11.2. Informative References
11.2. 有益な参照
[BOER91] den Boer, B. and A. Bosselaers, "An Attack on the Last Two
Rounds of MD4", Proceedings of the 11th Annual
International Cryptology Conference on Advances in
Cryptology, pages: 194 - 203, 1991.
[BOER91]穴ボーア人、B.、およびA.のBosselaers、「MD4"の最後の2ラウンドに対する攻撃(暗号理論における進歩の第11年に一度の国際暗号理論コンファレンスの議事)は以下を呼び出します」。 194 - 203, 1991.
[FMcG] Fluhrer, S. and D. McGrew, "Statistical Analysis of the
Alleged RC4 Keystream Generator", Fast Software
Encryption: 7th International Workshop, FSE 2000, April
2000, <http://www.mindspring.com/~dmcgrew/rc4-03.pdf>.
[FMcG] FluhrerとS.とD.マグリュー、「申し立てられたRC4 Keystreamジェネレータの統計分析」、速いソフトウェア暗号化: 第7国際ワークショップ、FSE2000、2000年4月、<http://www.mindspring.com/~dmcgrew/rc4-03.pdf>。
Jaganathan, et al. Informational [Page 16] RFC 4757 RC4-HMAC December 2006
Jaganathan、他 [16ページ]情報のRFC4757RC4-HMAC2006年12月
[MANTIN05] Mantin, I., "Predicting and Distinguishing Attacks on RC4
Keystream Generator", Advances in Cryptology -- EUROCRYPT
2005: 24th Annual International Conference on the Theory
and Applications of Cryptographic Techniques, May 2005.
[MANTIN05]Mantin(「RC4 Keystreamジェネレータに対する攻撃を予測して、区別する」I.)はEUROCRYPT2005年に暗号理論--進みます: 理論に関する第24年に一度の国際会議と暗号のテクニック、2005年5月のアプリケーション。
[MIRONOV] Mironov, I., "(Not So) Random Shuffles of RC4", Advances
in Cryptology -- CRYPTO 2002: 22nd Annual International
Cryptology Conference, August 2002,
<http://eprint.iacr.org/2002/067.pdf>.
[ミロノフ]ミロノフ、I.、「RC4"の(Not So)の無作為のシャッフル、暗号理論における進歩--暗号2002:、」 第22年に一度の国際暗号理論コンファレンス、2002年8月、<http://eprint.iacr.org/2002/067.pdf>。
[WANG04] Wang, X., Lai, X., Feng, D., Chen, H., and X. Yu,
"Cryptanalysis of Hash functions MD4 and RIPEMD", August
2004, <http://www.infosec.sdu.edu.cn/paper/md4-ripemd-
attck.pdf>.
[WANG04] ワング、X.、レイ、X.、フォン、D.、チェン、H.、およびX.ユー、「Hash機能のMD4とRIPEMDの暗号文解読術」、2004年8月(<http://www.infosec.sdu.edu.cn/紙/md4-ripemd- attck.pdf>)。
Authors' Addresses
作者のアドレス
Karthik Jaganathan Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
Karthik Jaganathanマイクロソフト社1マイクロソフト、道のワシントン98052レッドモンド(米国)
EMail: karthikj@microsoft.com
メール: karthikj@microsoft.com
Larry Zhu Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
ラリー朱マイクロソフト社1マイクロソフト、道のワシントン98052レッドモンド(米国)
EMail: lzhu@microsoft.com
メール: lzhu@microsoft.com
John Brezak Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
ジョンBrezakマイクロソフト社1マイクロソフト、道のワシントン98052レッドモンド(米国)
EMail: jbrezak@microsoft.com
メール: jbrezak@microsoft.com
Jaganathan, et al. Informational [Page 17] RFC 4757 RC4-HMAC December 2006
Jaganathan、他 [17ページ]情報のRFC4757RC4-HMAC2006年12月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(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, THE IETF TRUST, 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、IETF信用、「そのままで」という基礎と貢献者の上で提供していて、そして、インターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Jaganathan, et al. Informational [Page 18]
Jaganathan、他 情報[18ページ]
一覧
スポンサーリンク
