[要約] RFC 2712は、Kerberos暗号スイートをTransport Layer Security（TLS）に追加するための仕様です。その目的は、TLSプロトコルを使用してセキュアな通信を行う際に、Kerberos認証を利用できるようにすることです。
Network Working Group A. Medvinsky
Request for Comments: 2712 Excite
Category: Standards Track M. Hur
CyberSafe Corporation
October 1999
Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)
Layer Security（TLS）を輸送するためのケルベロス暗号スイートの追加
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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ビットの暗号スイートは、のみ暗号スイートのコードが既に割り当てられているという事実を文書化する目的のために含まれています。 40ビットの暗号スイートは、米国を中心とし、現在は廃止、輸出規制に準拠するように設計されました。彼らは安全なことはありませんでした、そして今日でさえカジュアルな用途には不十分です。実装と、この文書で定義された40ビットの暗号スイートの使用、および他の場所では、強くお勧めします。
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.
この文書では、[1] Kerberosベースの認証をサポートするために、TLSプロトコルに新しい暗号スイートの追加を提案しています。 Kerberos証明書は、相互認証を達成するために、その後、クライアント - サーバ間の通信を保護するために使用されたマスターシークレットを確立するために使用されています。
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 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.
柔軟性は、TLSプロトコルの主な強みの一つです。クライアントとサーバーは、特定のセキュリティおよび管理ポリシーを満たすために暗号スイートを交渉することができます。しかし、現在までに、TLSでの認証は、公開鍵のみのソリューションに限定されています。その結果、TLSは完全に対称暗号に基づく認証システムを含め、異種セキュリティの展開と組織をサポートしていません。元々MITで開発されたケルベロスは、オープンスタンダードに基づいている[2]及び最も広く展開対称鍵認証システムです。この文書では、TLSフレームワーク内でKerberos認証を交渉するための新しいオプションを提案しています。これは、相互認証とKerberos資格情報を使用してマスターシークレットの確立を実現しています。提案された変更は最小限と、実際には、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プロトコルへのKerberos認証オプションの追加について説明します。このドキュメントでは、我々は、TLSハンドシェイク[1]を参照のレビューについては、図1に示した基本的なSSLハンドシェイクを参照してください。
CLIENT SERVER
------ ------
ClientHello
-------------------------------->
ServerHello
Certificate *
ServerKeyExchange*
CertificateRequest*
ServerHelloDone
<-------------------------------
Certificate*
ClientKeyExchange
CertificateVerify*
change cipher spec
Finished
| -------------------------------->
| change cipher spec
| Finished
| |
| |
Application Data <------------------------------->Application Data
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のセキュリティコンテキストでは、クライアントとサーバーのhelloメッセージに交渉されています。たとえば：TLS_RSA_WITH_RC4_MD5は、初期認証がRSA公開鍵アルゴリズムを使用して行われることを意味し、RC4は、セッションキーのために使用され、MACはMD5アルゴリズムに基づいて行われます。したがって、Kerberos認証オプションを容易にするため、我々は、（これらに限定されない）を含む、新しい暗号スイートを定義することから始めなければなりません。
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 };
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 };
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
Kerberosベースのセキュリティコンテキストを確立するために、上記の暗号スイートの1以上は、クライアントのhelloメッセージで指定する必要があります。 TLSサーバは、Kerberos認証オプションをサポートしている場合は、クライアントに送信され、サーバハローメッセージは、サーバによって選択されたケルベロス暗号スイートを確認します。サーバの証明書、クライアント
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、図1に示すServerKeyExchangeは、認証ので、省略され、マスタシークレットの確立はTLSサーバ用クライアントのKerberos資格情報を使用して行われます。クライアントの証明書は、同じ理由で省略されます。これらのメッセージは、TLSプロトコルでオプションとして指定されていることに注意してください。そのため、それらを省略することは許されます。
The Kerberos option must be added to the ClientKeyExchange message as shown in Figure 2.
図2に示すように、ケルベロス・オプションは、ClientKeyExchangeメッセージに追加されなければなりません。
struct
{
select (KeyExchangeAlgorithm)
{
case krb5: KerberosWrapper; /* new addition */
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: ClientDiffieHellmanPublic;
} Exchange_keys;
} ClientKeyExchange;
} ClientKeyExchange。
struct
{
opaque Ticket;
opaque authenticator; /* optional */
opaque EncryptedPreMasterSecret; /* encrypted with the session key
which is sealed in the ticket */
} KerberosWrapper; /* new addition */
FIGURE 2: The Kerberos option in the ClientKeyExchange.
図2：ClientKeyExchangeでのKerberosオプション。
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.
Kerberos認証オプションを使用するには、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の計算に使用されているマスターシークレットを、導出するプレマスターシークレットを使用しています。 Kerberosのオプションが選択されている場合したがって、プリマスターシークレット構造は、RSAの場合に使用されるものと同じです。それはケルベロスセッション鍵で暗号化し、Kerberos証明書と一緒にTLSサーバーに送信されます（図2を参照）。チケットとオーセンティケータは、RFC 1510（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).
クライアントとサーバによって導出マスターシークレットは、このようにリプレイ攻撃をfoiling、サーバーハローメッセージで渡された乱数値が播種されているのでケルベロスオーセンティケータは、必要とされていないことに注意してください。しかし、オーセンティケータは、まだ認証情報を渡すために有用であることを証明することができるので、（図2を参照）オプションのフィールドが割り当てられています。
Lastly, the client and server exchange the finished messages to complete the handshake. At this point we have achieved the following:
最後に、クライアントとサーバーはハンドシェイクを完了するために、完成したメッセージを交換します。この時点で、私たちは次のことを達成しました。
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.
TLSサーバは、完成したメッセージでマスターシークレットの知識を証明するため、2）相互クライアントサーバ認証は、達成されます。
Note that the Kerberos option fits in seamlessly, without adding any new messages.
Kerberosのオプションは、任意の新しいメッセージを追加することなく、シームレスで収まることに注意してください。
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サーバのプリンシパル名を決定する必要があります。次のようにKerberosサービスの命名規則は、この目的のために使用されます。
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.
ホスト/ MachineNameにする@レルム： - 文字通り、「ホスト」、ときに、特定のマシン上の保護ドメインを懸念していないKerberosの規則に従います。 - 「MachineNameには、」サービスの特定のインスタンスです。 - Kerberosの「レルム」、マシンのドメイン名です。
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に追加されるように提案したKerberos認証のオプションは、まったく同じ方法で追加されます。さらに、それはまったく同じ方法でマスターシークレットを確立します。
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).
ケルベロス暗号スイートは、TLSプロトコルと同じセキュリティ上の考慮の対象となっています。また、公開鍵の実装は、（例えば、スマートカードのPIN）の秘密鍵を保護するために注意しなければならないのと同様に、Kerberos実装は、元本とKDC間で共有されている長命秘密を保護するために注意しなければなりません。特に、弱いパスワードは辞書攻撃を受ける可能性があります。 KDCへの初期の認証を強化するために、実装者は、トークン・カードを介して二次認証を利用することを選択することができる、または1つは、一般PKINITとして知られている公開鍵暗号（に基づいて、KDCに初期認証を利用することができる - 共通認証の積IETFの技術ワーキンググループ）。
We would like to thank Clifford Neuman for his invaluable comments on earlier versions of this document.
私たちは、この文書の以前のバージョンの彼の貴重なコメントをクリフォードノイマンに感謝したいと思います。
[1] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0", RFC 2246, January 1999.
[1]ダークス、T.とC.アレン、 "TLSプロトコル、バージョン1.0"、RFC 2246、1999年1月。
[2] Kohl J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[2]コールズJ.とC.ノイマン、 "ケルベロスネットワーク認証サービス（V5）"、RFC 1510、1993年9月。
Ari Medvinsky Excite 555 Broadway Redwood City, CA 94063
アリMedvinskyエキサイト555ブロードウェイレッドウッドシティ、CA 94063
Phone: +1 650 569 2119 EMail: amedvins@excitecorp.com http://www.excite.com
電話：+1 650 569 2119 Eメール：amedvins@excitecorp.com http://www.excite.com
Matthew Hur CyberSafe Corporation 1605 NW Sammamish Road Issaquah WA 98027-5378
マシュー・ハーのCyberSafe株式会社1605 NWサマミッシュ道路イサクアWA 98027から5378
Phone: +1 425 391 6000 EMail: matt.hur@cybersafe.com http://www.cybersafe.com
電話：+1 425 391 6000 Eメール：matt.hur@cybersafe.com http://www.cybersafe.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。