RFC2712 日本語訳
2712 Addition of Kerberos Cipher Suites to Transport Layer Security(TLS). A. Medvinsky, M. Hur. October 1999. (Format: TXT=13763 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Medvinsky
Request for Comments: 2712 Excite
Category: Standards Track M. Hur
CyberSafe Corporation
October 1999
Medvinskyがコメントのために要求するワーキンググループA.をネットワークでつないでください: 2712年のExciteカテゴリ: 標準化過程M.Hur CyberSafe社の1999年10月
Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)
トランスポート層セキュリティへのケルベロス暗号スイートの追加(TLS)
Status of this Memo
この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 (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
IESG Note:
IESGは以下に注意します。
The 40-bit ciphersuites defined in this memo are included only for the purpose of documenting the fact that those ciphersuite codes have already been assigned. 40-bit ciphersuites were designed to comply with US-centric, and now obsolete, export restrictions. They were never secure, and nowadays are inadequate even for casual applications. Implementation and use of the 40-bit ciphersuites defined in this document, and elsewhere, is strongly discouraged.
このメモで定義された40ビットのciphersuitesは既にそれらのciphersuiteコードを割り当ててあるという事実を記録する目的のためだけに含まれています。 40ビットのciphersuitesは、米国に中心の、そして、現在時代遅れの輸出制限に従うように設計されました。 それらは、決して安全でなく、またこの頃は、カジュアルなアプリケーションにさえ不十分ではありません。 本書ではと、ほかの場所で定義された40ビットのciphersuitesの実装と使用は強くお勧めできないです。
1. Abstract
1. 要約
This document proposes the addition of new cipher suites to the TLS protocol [1] to support Kerberos-based authentication. Kerberos credentials are used to achieve mutual authentication and to establish a master secret which is subsequently used to secure client-server communication.
このドキュメントは、ケルベロスベースの認証をサポートするために新しい暗号スイートの追加をTLSプロトコル[1]に提案します。 ケルベロス資格証明書は、互いの認証を達成して、次にクライアント/サーバコミュニケーションを保証するのに使用されるマスター秘密を証明するのに使用されます。
2. Introduction
2. 序論
Flexibility is one of the main strengths of the TLS protocol. Clients and servers can negotiate cipher suites to meet specific security and administrative policies. However, to date, authentication in TLS is limited only to public key solutions. As a result, TLS does not fully support organizations with heterogeneous security deployments that include authentication systems based on symmetric cryptography. Kerberos, originally developed at MIT, is
柔軟性はTLSプロトコルの主な強さの1つです。 クライアントとサーバは、特定のセキュリティと施政方針を満たすために暗号スイートを交渉できます。 しかしながら、これまで、TLSでの認証は公開鍵ソリューションだけに制限されます。 その結果、TLSは左右対称の暗号に基づく認証システムを含んでいる異種のセキュリティ展開で完全に組織をサポートするというわけではありません。 ケルベロス、元々開発されたMITはそうです。
Medvinsky & Hur Standards Track [Page 1] RFC 2712 Addition of Kerberos Cipher Suites to TLS October 1999
Medvinsky&Hur規格は1999年10月にケルベロス暗号スイートのRFC2712追加をTLSに追跡します[1ページ]。
based on an open standard [2] and is the most widely deployed symmetric key authentication system. This document proposes a new option for negotiating Kerberos authentication within the TLS framework. This achieves mutual authentication and the establishment of a master secret using Kerberos credentials. The proposed changes are minimal and, in fact, no different from adding a new public key algorithm to the TLS framework.
オープンスタンダード[2]を基礎づけて、対称鍵認証システムであると最も広く配布されます。 このドキュメントはTLSフレームワークの中でケルベロス認証を交渉するための新しいオプションを提案します。 これは、ケルベロス資格証明書を使用することでマスター秘密の互いの認証と確立を達成します。 変更案は、新しい公開鍵アルゴリズムをTLSフレームワークに加えるのと最小量であって事実上、異なっていません。
3. Kerberos Authentication Option In TLS
3. TLSのケルベロス認証オプション
This section describes the addition of the Kerberos authentication option to the TLS protocol. Throughout this document, we refer to the basic SSL handshake shown in Figure 1. For a review of the TLS handshake see [1].
このセクションはケルベロス認証オプションの追加についてTLSプロトコルに説明します。 このドキュメント中では、私たちは図1に示された基本的なSSL握手について言及します。 TLS握手のレビューに関しては、[1]を見てください。
CLIENT SERVER
------ ------
ClientHello
-------------------------------->
ServerHello
Certificate *
ServerKeyExchange*
CertificateRequest*
ServerHelloDone
<-------------------------------
Certificate*
ClientKeyExchange
CertificateVerify*
change cipher spec
Finished
| -------------------------------->
| change cipher spec
| Finished
| |
| |
Application Data <------------------------------->Application Data
クライアントサーバ------ ------ ClientHello-------------------------------->ServerHello証明書*ServerKeyExchange*CertificateRequest*ServerHelloDone<。------------------------------- 証明書*ClientKeyExchange CertificateVerify*変化暗号仕様Finished| -------------------------------->| 変化暗号仕様| 終わっています。| | | | アプリケーションデータ<。------------------------------->アプリケーションデータ
FIGURE 1: The TLS protocol. All messages followed by a star are
optional. Note: This figure was taken from an IETF document
[1].
1図: TLSは議定書を作ります。 星によって従われたすべてのメッセージが任意です。 以下に注意してください。 この図はIETFドキュメント[1]から抜粋されました。
The TLS security context is negotiated in the client and server hello messages. For example: TLS_RSA_WITH_RC4_MD5 means the initial authentication will be done using the RSA public key algorithm, RC4 will be used for the session key, and MACs will be based on the MD5 algorithm. Thus, to facilitate the Kerberos authentication option, we must start by defining new cipher suites including (but not limited to):
TLSセキュリティ文脈がクライアントとサーバで交渉される、こんにちは、メッセージ。 例えば: TLS_RSA_WITH_RC4_MD5は、初期の認証がRSA公開鍵アルゴリズムを使用し終わることを意味します、そして、RC4はセッションキーに使用されるでしょう、そして、MACsはMD5アルゴリズムに基づくでしょう。 したがって、ケルベロス認証オプションを容易にするために、私たちは(他)を含む新しい暗号スイートを定義することによって、始めなければなりません:
Medvinsky & Hur Standards Track [Page 2] RFC 2712 Addition of Kerberos Cipher Suites to TLS October 1999
Medvinsky&Hur規格は1999年10月にケルベロス暗号スイートのRFC2712追加をTLSに追跡します[2ページ]。
CipherSuite TLS_KRB5_WITH_DES_CBC_SHA = { 0x00,0x1E };
CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1F };
CipherSuite TLS_KRB5_WITH_RC4_128_SHA = { 0x00,0x20 };
CipherSuite TLS_KRB5_WITH_IDEA_CBC_SHA = { 0x00,0x21 };
CipherSuite TLS_KRB5_WITH_DES_CBC_MD5 = { 0x00,0x22 };
CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x23 };
CipherSuite TLS_KRB5_WITH_RC4_128_MD5 = { 0x00,0x24 };
CipherSuite TLS_KRB5_WITH_IDEA_CBC_MD5 = { 0x00,0x25 };
_DES_CBC_SHAとCipherSuite TLS_KRB5_は0×00、0x1Eと等しいです。 _3DES_EDE_CBC_SHAとCipherSuite TLS_KRB5_は0×00、0x1Fと等しいです。 0×00、_RC4_128_SHAとCipherSuite TLS_KRB5_=0×20。 0×00、_考え_CBC_SHAとCipherSuite TLS_KRB5_=0×21。 _DES0×00、_CBC_MD5=0x22とCipherSuite TLS_KRB5_。 0×00、_3DES_EDE_CBC_MD5とCipherSuite TLS_KRB5_=0×23。 0×00、_RC4_128_MD5とCipherSuite TLS_KRB5_=0×24。 0×00、_考え_CBC_MD5とCipherSuite TLS_KRB5_=0×25。
CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA = { 0x00,0x26 };
CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA = { 0x00,0x27 };
CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_SHA = { 0x00,0x28 };
CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 = { 0x00,0x29 };
CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x2A };
CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x2B };
0×00、_DES_CBC_40_SHA=0×26があるCipherSuite TLS_KRB5_輸出_。 0×00、_RC2_CBC_40_SHA=0×27があるCipherSuite TLS_KRB5_輸出_。 0×00、_RC4_40_SHA=0×28があるCipherSuite TLS_KRB5_輸出_。 0×00、_DES_CBC_40_MD5=0×29があるCipherSuite TLS_KRB5_輸出_。 _RC2_CBC_40_MD5とCipherSuite TLS_KRB5_輸出_は0×00、0x2Aと等しいです。 _RC4_40_MD5とCipherSuite TLS_KRB5_輸出_は0×00、0x2Bと等しいです。
To establish a Kerberos-based security context, one or more of the above cipher suites must be specified in the client hello message. If the TLS server supports the Kerberos authentication option, the server hello message, sent to the client, will confirm the Kerberos cipher suite selected by the server. The server's certificate, the client
こんにちはとケルベロスベースのセキュリティ文脈、1つまたはさらにスイートが指定されたコネがクライアントであったならそうしなければならない上の暗号を証明するには、通信してください。 TLSサーバがケルベロス認証オプション、サーバをサポートする、こんにちは、クライアントに送られたメッセージは、ケルベロス暗号スイートが. サーバの証明書、サーバによるクライアントを選んだと確認するでしょう。
CertificateRequest, and the ServerKeyExchange shown in Figure 1 will be omitted since authentication and the establishment of a master secret will be done using the client's Kerberos credentials for the TLS server. The client's certificate will be omitted for the same reason. Note that these messages are specified as optional in the TLS protocol; therefore, omitting them is permissible.
CertificateRequest、およびサーバクライアントのものが証明するTLSが同じ理由から省略されるのでクライアントのケルベロス資格証明書を使用する図1にマスター秘密の認証と確立をするので省略されるのが示されたServerKeyExchange。 これらのメッセージがTLSプロトコルで任意であるとして指定されることに注意してください。 したがって、それらを省略するのは許されています。
The Kerberos option must be added to the ClientKeyExchange message as shown in Figure 2.
図2に示されるようにケルベロスオプションをClientKeyExchangeメッセージに追加しなければなりません。
Medvinsky & Hur Standards Track [Page 3] RFC 2712 Addition of Kerberos Cipher Suites to TLS October 1999
Medvinsky&Hur規格は1999年10月にケルベロス暗号スイートのRFC2712追加をTLSに追跡します[3ページ]。
struct
{
select (KeyExchangeAlgorithm)
{
case krb5: KerberosWrapper; /* new addition */
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: ClientDiffieHellmanPublic;
} Exchange_keys;
(KeyExchangeAlgorithm)を選択してください。struct、ケースkrb5: /*新しい追加*/ケースrsa: EncryptedPreMasterSecret; diffie_hellman: ClientDiffieHellmanPublicをケースに入れるというKerberosWrapperは_キーを交換します。
} ClientKeyExchange;
} ClientKeyExchange。
struct
{
opaque Ticket;
opaque authenticator; /* optional */
opaque EncryptedPreMasterSecret; /* encrypted with the session key
which is sealed in the ticket */
} KerberosWrapper; /* new addition */
{*Ticket; 不明瞭な固有識別文字;/任意の*/不透明なEncryptedPreMasterSecretについて不透明にしてください; チケット*/で堅く閉じられているセッションキーで暗号化された/*}というstruct KerberosWrapper。 /*新しい追加*/
FIGURE 2: The Kerberos option in the ClientKeyExchange.
2は計算します: ClientKeyExchangeのケルベロスオプション。
To use the Kerberos authentication option, the TLS client must obtain a service ticket for the TLS server. In TLS, the ClientKeyExchange message is used to pass a random 48-byte pre-master secret to the server.
ケルベロス認証オプションを使用するために、TLSクライアントはTLSサーバのサービスチケットを得なければなりません。TLSでは、ClientKeyExchangeメッセージは、無作為の48バイトのプレマスター秘密をサーバに通過するのに使用されます。
The client and server then use the pre-master secret to independently derive the master secret, which in turn is used for generating session keys and for MAC computations. Thus, if the Kerberos option is selected, the pre-master secret structure is the same as that used in the RSA case; it is encrypted under the Kerberos session key and sent to the TLS server along with the Kerberos credentials (see Figure 2). The ticket and authenticator are encoded per RFC 1510 (ASN.1 encoding). Once the ClientKeyExchange message is received, the server's secret key is used to unwrap the credentials and extract the pre-master secret.
そして、クライアントとサーバは、独自に、マスター秘密を引き出すのにプレマスター秘密を使用します。(それは、セッションキーを生成して、MAC計算に順番に使用されます)。 したがって、ケルベロスオプションが選択されるなら、プレマスターの秘密の構造はRSA場合に使用されるそれと同じです。 それをケルベロスセッションキーの下で暗号化して、ケルベロス資格証明書に伴うTLSサーバに送ります(図2を見てください)。 チケットと固有識別文字はRFC1510(ASN.1コード化)単位でコード化されます。 ClientKeyExchangeメッセージがいったん受信されるようになると、サーバの秘密鍵は、資格証明書を開けて、プレマスター秘密を抜粋するのに使用されます。
Note that a Kerberos authenticator is not required, since the master secret derived by the client and server is seeded with a random value passed in the server hello message, thus foiling replay attacks. However, the authenticator may still prove useful for passing authorization information and is thus allotted an optional field (see Figure 2).
ケルベロス固有識別文字は必要でないことに注意してください、無作為の値がサーバで通過されている状態でクライアントとサーバで引き出されたマスター秘密に種を蒔かれるのでこんにちは、その結果反射攻撃をくじくメッセージ。 しかしながら、固有識別文字は承認情報を通過するためにまだ有用であることが分かっているかもしれなくて、このようにして任意の分野を割り当てられます(図2を見てください)。
Lastly, the client and server exchange the finished messages to complete the handshake. At this point we have achieved the following:
最後に、クライアントとサーバは握手を終了する終わっているメッセージを交換します。 ここに、私たちは以下を達成しました:
Medvinsky & Hur Standards Track [Page 4] RFC 2712 Addition of Kerberos Cipher Suites to TLS October 1999
Medvinsky&Hur規格は1999年10月にケルベロス暗号スイートのRFC2712追加をTLSに追跡します[4ページ]。
1) A master secret, used to protect all subsequent communication, is
securely established.
1) すべてのその後のコミュニケーションを保護するのに使用されるマスター秘密はしっかりと確立されます。
2) Mutual client-server authentication is achieved, since the TLS
server proves knowledge of the master secret in the finished
message.
2) TLSサーバが、マスターに関する知識が終わっているメッセージで秘密であると立証するので、互いのクライアント/サーバ認証は達成されます。
Note that the Kerberos option fits in seamlessly, without adding any new messages.
ケルベロスオプションがシームレスにどんな新しいメッセージも加えないで適合することに注意してください。
4. Naming Conventions:
4. 命名規則:
To obtain an appropriate service ticket, the TLS client must determine the principal name of the TLS server. The Kerberos service naming convention is used for this purpose, as follows:
適切なサービスチケットを得るために、TLSクライアントはTLSサーバの主要な名前を決定しなければなりません。ケルベロスサービス命名規則はこのために使用されます、以下の通りです:
host/MachineName@Realm
where:
- The literal, "host", follows the Kerberos convention when not
concerned about the protection domain on a particular machine.
- "MachineName" is the particular instance of the service.
- The Kerberos "Realm" is the domain name of the machine.
host/MachineName@Realm 、どこ: - 特定のマシンの上の保護ドメインに関して心配していないと、「ホスト」というリテラルはケルベロスコンベンションに続きます。 - "MachineName"は特定のサービスのインスタンスです。 - ケルベロス「分野」はマシンのドメイン名です。
5. Summary
5. 概要
The proposed Kerberos authentication option is added in exactly the same manner as a new public key algorithm would be added to TLS. Furthermore, it establishes the master secret in exactly the same manner.
提案されたケルベロス認証オプションは新しい公開鍵アルゴリズムがTLSに加えられるようなまさに同じ方法で加えられます。 その上、それはまさに同じ方法によるマスター秘密を確立します。
6. Security Considerations
6. セキュリティ問題
Kerberos ciphersuites are subject to the same security considerations as the TLS protocol. In addition, just as a public key implementation must take care to protect the private key (for example the PIN for a smartcard), a Kerberos implementation must take care to protect the long lived secret that is shared between the principal and the KDC. In particular, a weak password may be subject to a dictionary attack. In order to strengthen the initial authentication to a KDC, an implementor may choose to utilize secondary authentication via a token card, or one may utilize initial authentication to the KDC based on public key cryptography (commonly known as PKINIT - a product of the Common Authentication Technology working group of the IETF).
ケルベロスciphersuitesはTLSプロトコルと同じセキュリティ問題を受けることがあります。 さらに、ちょうど公開鍵実装が秘密鍵(例えば、スマートカードのための暗証番号)を保護するために注意されなければならないようにケルベロス実装は、主体とKDCの間で共有される長い送られた秘密を保護するために注意されなければなりません。 弱いパスワードは辞書攻撃を特に、受けることがあるかもしれません。 初期の認証をKDCに強化するために、作成者が、トークン・カードを通してセカンダリ認証を利用するのを選ぶかもしれませんか、または公開鍵暗号(一般的に知られているPKINIT--IETFのCommon Authentication Technologyワーキンググループの製品)に基づくKDCに初期の認証を利用するかもしれません。
Medvinsky & Hur Standards Track [Page 5] RFC 2712 Addition of Kerberos Cipher Suites to TLS October 1999
Medvinsky&Hur規格は1999年10月にケルベロス暗号スイートのRFC2712追加をTLSに追跡します[5ページ]。
7. Acknowledgements
7. 承認
We would like to thank Clifford Neuman for his invaluable comments on earlier versions of this document.
このドキュメントの以前のバージョンの彼の非常に貴重なコメントについてクリフォード・ヌーマンに感謝申し上げます。
8. References
8. 参照
[1] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0", RFC
2246, January 1999.
[1] Dierks、T.、およびC.アレン、「TLSはRFC2246、1999年1月についてバージョン1インチ議定書の中で述べます」。
[2] Kohl J. and C. Neuman, "The Kerberos Network Authentication
Service (V5)", RFC 1510, September 1993.
[2] コールJ.とC.ヌーマン、「ケルベロスネットワーク認証サービス(V5)」、RFC1510 1993年9月。
9. Authors' Addresses
9. 作者のアドレス
Ari Medvinsky Excite 555 Broadway Redwood City, CA 94063
Broadwayレッドウッドシティー、アリMedvinsky Excite555カリフォルニア 94063
Phone: +1 650 569 2119 EMail: amedvins@excitecorp.com http://www.excite.com
以下に電話をしてください。 +1 2119年の650 569メール: amedvins@excitecorp.com http://www.excite.com
Matthew Hur CyberSafe Corporation 1605 NW Sammamish Road Issaquah WA 98027-5378
マシューHur CyberSafe社1605のNWサマミシュ道路イサクアーワシントン98027-5378
Phone: +1 425 391 6000 EMail: matt.hur@cybersafe.com http://www.cybersafe.com
以下に電話をしてください。 +1 6000年の425 391メール: matt.hur@cybersafe.com http://www.cybersafe.com
Medvinsky & Hur Standards Track [Page 6] RFC 2712 Addition of Kerberos Cipher Suites to TLS October 1999
Medvinsky&Hur規格は1999年10月にケルベロス暗号スイートのRFC2712追加をTLSに追跡します[6ページ]。
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Medvinsky & Hur Standards Track [Page 7]
Medvinsky&Hur標準化過程[7ページ]
一覧
スポンサーリンク
