Network Working Group M. Thomas
Request for Comments: 3129 Cisco Systems
Category: Informational June 2001
Requirements for Kerberized Internet Negotiation of Keys
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 Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
The goal of this document is to produce a streamlined, fast, easily managed, and cryptographically sound protocol without requiring public key.
このドキュメントの目標は、公開鍵を必要とせずに、合理化、高速、簡単に管理、および暗号的に音プロトコルを生成することです。
Motivation
動機
The IPsec working group has defined a number of protocols which provide the ability to create and maintain cryptographically secure security associations at layer three (i.e., the IP layer). This effort has produced two distinct protocols:
IPsecのワーキンググループは、レイヤ3（すなわち、IP層）で暗号的に安全なセキュリティアソシエーションを作成し、維持する能力を提供するプロトコルの数を定義しています。この取り組みは、2つの異なるプロトコルを生産しています：
1) a mechanism to encrypt and authenticate IP datagram payloads which assumes a shared secret between the sender and receiver
送信側と受信側の間の共有秘密を前提とIPデータグラムのペイロードを暗号化および認証する1）機構
2) a mechanism for IPsec peers to perform mutual authentication and exchange keying material
2）IPsecピアは、相互認証および鍵材料交換を実行するための機構を
The IPsec working group has defined a peer to peer authentication and keying mechanism, IKE (RFC 2409). One of the drawbacks of a peer to peer protocol is that each peer must know and implement a site's security policy which in practice can be quite complex. In addition, the lack of a trusted third party requires the use of Diffie Hellman (DH) to establish a shared secret. DH, unfortunately, is computationally quite expensive and prone to denial of service attacks. IKE also relies on X.509 certificates to realize scalable authentication of peers. Digital signatures are also computationally expensive and certificate based trust models are difficult to deploy in practice. While IKE does allow for pre-shared symmetric keys, key distribution is required between all peers -- an O(n^2) problem -- which is problematic for large deployments.
IPsecのワーキンググループは、認証およびキーイングメカニズム、IKE（RFC 2409）ピア・ツー・ピアを定義しています。プロトコルをピア・ツー・ピアの欠点の1つは、各ピアが知っていて、サイトのセキュリティポリシー実際にはかなり複雑になる可能性が実装しなければならないということです。また、信頼できるサードパーティの欠如は、共有秘密を確立するためのDiffieヘルマン（DH）を使用する必要があります。 DHは、残念ながら、計算が非常に高価で、サービス拒否攻撃を受けやすいです。 IKEはまた、ピアのスケーラブルな認証を実現するために、X.509証明書に依存しています。デジタル署名はまた、計算コストが高いと証明書ベースの信頼モデルは、実際に展開することは困難です。 O（N ^ 2）問題 - - 大規模な展開のために問題があるIKE事前共有対称鍵を許可ないが、キー配布は、すべてのピア間で必要とされます。
Kerberos (RFC 1510) provides a mechanism for trusted third party authentication for clients and servers. Clients authenticate to a centralized server -- the Key Distribution Center -- which in turn issues tickets that servers can decrypt thus proving that the client is who it claims to be. One of the elements of a Kerberos ticket is a session key which is generated by the KDC which may be used by the client and server to share a secret. Kerberos also allows for both symmetric key authentication, as well as certificate based public key authentication (PKinit). Since the authentication phase of Kerberos is performed by the KDC, there is no need to perform expensive DH or X.509 certificate signatures/verification operations on servers. While clients may authenticate using X.509 certificates, the authentication phase can be amortized over the lifetime of the credentials. This allows a single DH and certificate exchange to be used to key security associations with many servers in a computationally economic way. Kerberos also support clients with symmetric keys but unlike IKE, the symmetric keys are stored in the KDC making the number of keys an O(n) problem rather than O(n^2). Kerberos also allows security policy to be managed in a more centralized fashion, rather than expecting each potentially untrustworthy peer to abide by stated security policies of an organization.
ケルベロス（RFC 1510）は、クライアントとサーバーのための信頼できる第三者認証のためのメカニズムを提供します。クライアントは、中央サーバへの認証 - キー配布センターを - 今度はサーバがクライアントがあることを主張する人であることを証明するため、復号化することができるチケットを発行します。 Kerberosチケットの要素の一つは、秘密を共有するために、クライアントとサーバーで使用できるKDCによって生成されたセッション鍵です。ケルベロスはまた、対称鍵認証、ならびに証明書ベースの公開鍵認証（PKINIT）の両方を可能にします。ケルベロスの認証フェーズがKDCによって実行されているので、サーバー上の高価なDHかX.509証明書の署名/検証操作を実行する必要はありません。クライアントは、X.509証明書を使用して認証することができるが、認証フェーズは、資格証明書の有効期間にわたって償却することができます。これは、単一のDHと証明書交換は、計算上、経済的な方法で多くのサーバを持つキーのセキュリティアソシエーションに使用することができます。 （N ^ 2）の問題ではなく、OをKerberosはまた、対称鍵を用いてクライアントをサポートするが、IKEとは異なり、対称鍵は、O（n）は、キーの数を作るKDCに格納されています。 Kerberosは、セキュリティポリシーではなく、組織の定められたセキュリティポリシーを遵守するために、各潜在的に信頼できないピアを期待するよりも、より集中的に管理することができます。
The KINK working group takes these basic features of Kerberos and uses them to its advantage to create a protocol which can establish and maintain IPsec security associations (RFC 2401). It should be noted that KINK is not a replacement for IKE. IKE has one property which KINK cannot reproduce: the ability for two peers to mutually authenticate and exchange keys without the need for an actively participating third party. However, there are many situations where a trusted third party which proxies authentication is viable, and in fact desirable.
KINKワーキンググループは、Kerberosのこれらの基本的な機能を取り込み、確立し、IPsecセキュリティアソシエーション（RFC 2401）を維持することができますプロトコルを作成するために、その利点にそれらを使用しています。 KINKがIKEに代わるものではありませんことに留意すべきです。相互に積極的に参加する第三者を必要とせずにキーを認証し、交換のための2つのピアの能力：IKEはKINKを再現することはできませんつのプロパティを持っています。ただし、プロキシ認証が実行可能であり、実際には望ましい信頼できるサードパーティ多くの状況があります。
While Kerberos specifies a standard protocol between the client and the KDC to get tickets, the actual ticket exchange between client and server is application specific. KINK is intended to be an alternative to requiring each application having its own method of transporting and validating service tickets using a protocol which is efficient and tailored to the specific needs of Kerberos and the applications for which it provides keying and parameter negotiation.
Kerberosがチケットを取得するには、クライアントとKDC間の標準プロトコルを指定しますが、クライアントとサーバ間の実際のチケット交換はアプリケーション固有のものです。 KINKは、効率的であり、ケルベロスの特定のニーズとそれをキーイングおよびパラメータネゴシエーションを提供するためのアプリケーションに合わせたプロトコルを使用してサービスチケットを搬送し、検証する独自の方法を有する各アプリケーションを必要とすることに代わることを意図しています。
Given the above, a new general keying protocol which leverages the scalability of Kerberos is desirable. The working group's first task is to define this protocol and define an domain of interpretation for
上記の、ケルベロスのスケーラビリティを活用し、新たな一般的なキーイングプロトコルが望ましいです。ワーキンググループの最初の仕事は、このプロトコルを定義し、ために解釈のドメインを定義することです
IPsec to establish and maintain IPsec security associations. The protocol must be able to take full advantage of the features of RFC 2401 but in the context of a centralized keying authority.
IPsecセキュリティアソシエーションを確立し、維持するためのIPsec。プロトコルはRFC 2401の機能を十分に活用することができますが、集中キーイング権限のコンテキストでなければなりません。
Requirements
必要条件
KINK must meet the following requirements at a minimum:
KINKは、最低でも次の要件を満たしている必要があります。
- The protocol must use the session keys found in Kerberos tickets as the basis of the keying material used for IPsec security association keys.
- プロトコルは、IPsecセキュリティアソシエーションのキーに使用する鍵素材の基礎としてKerberosチケットで見つかったセッションキーを使用する必要があります。
- The protocol must be able to integrate into security architecture of IPsec (RFC 2401).
- プロトコルは、IPsecのセキュリティアーキテクチャ（RFC 2401）に統合することができなければなりません。
- The protocol must be able to start up SA's regardless of any client/server disposition in the keying protocol. In other words, either IPsec peer can be the initiator or responder, regardless of whether it's a Kerberos 'client' (TGT-only) or Kerberos 'server'(has a keytab).
- プロトコルに関係なく、キーイングプロトコルにおける任意のクライアント/サーバ・処分のSAのを起動することができなければなりません。言い換えれば、IPsecピアのいずれかにかかわらず、それはケルベロス「クライアント」（TGT-のみ）またはKerberos「サーバ」（キータブを持っている）のかどうかの、イニシエータまたは応答することができます。
- The protocol must support Kerberos using either secret key, or public key (PKINIT) initial authentication.
- プロトコルは、秘密鍵、または公開鍵（PKINIT）初期認証のいずれかを使用してKerberosをサポートしている必要があります。
- The protocol must support Kerberos User-to-User mode for cases in which the initiator cannot obtain an AP_REQ for the responder (i.e. the responder is a PKINIT client) or the responder cannot decrypt and AP_REQ from the initiator (i.e., the responder doesn't have a Kerberos Keytab, just a TGT).
- プロトコル（すなわちレスポンダがPKINITクライアントである）イニシエータがレスポンダためAP_REQを得ることができない場合にKerberosユーザ対ユーザモードをサポートしなければならないか、レスポンダは、イニシエータ（すなわち、レスポンダーのdoesnから復号しAP_REQことができません「Tは、Kerberosキータブ、ちょうどTGT）を持っています。
- The protocol must be able to allow a peer to authenticate and participate in many realms.
- プロトコルは、ピアが認証し、多くのレルムに参加できるようにすることができなければなりません。
- The protocol must handle absolute time skew gracefully.
- プロトコルは優雅に絶対時間スキューを処理する必要があります。
- The protocol must be able to create, modify, rekey, and delete security associations.
- プロトコルは、セキュリティアソシエーションを作成、変更、キーの再生成、および削除することができなければなりません。
- The protocol must be capable of setting up both transport and tunnel modes of IPsec.
- プロトコルは、IPsecの両方のトランスポートモードとトンネルモードを設定することができなければなりません。
- The protocol must be capable of setting up both AH and ESP security associations.
- プロトコルは、両方のAHとESPセキュリティアソシエーションを設定することが可能でなければなりません。
- The protocol must be capable of negotiating cipher suites.
- プロトコルは、暗号スイートを交渉することが可能でなければなりません。
- The protocol must be capable of setting up IPsec flow selectors.
- プロトコルは、IPsecの流れセレクタを設定することが可能でなければなりません。
- The protocol must be capable of rekeying without the assistance of the KDC if the Kerberos session ticket is still valid.
- ケルベロスセッションチケットがまだ有効である場合、プロトコルは、KDCの支援なしに再入力することが可能でなければなりません。
- The protocol must make an effort to mitigate third party Denial of Service attacks (aka Zombies attacks).
- プロトコルは、サービスの攻撃（通称ゾンビ攻撃）のサードパーティの妨害を軽減する努力をしなければなりません。
- The protocol must be able to be used for more than IPsec keying.
- プロトコルは、IPsecキーイング以上のために使用することができなければなりません。
- The protocol must support both IPv4 and IPv6.
- プロトコルはIPv4とIPv6の両方をサポートしている必要があります。
Security Considerations
セキュリティの考慮事項
These requirements lay out input to define a protocol which allows the keying of IPsec security associations using Kerberos as the key distribution mechanism. As such, the security associations that will be created by the new protocol will inherit the union of IPsec and Kerberos's existing security weaknesses. There is no requirement to address those weaknesses unless in combination they produce a new weakness which is not inherent in other keying protocols.
これらの要件は、鍵配布メカニズムとしてKerberosを使用してIPsecセキュリティアソシエーションのキーイングを可能にするプロトコルを定義するために入力をレイアウト。そのため、新しいプロトコルによって作成されるセキュリティアソシエーションは、IPsecおよびKerberosの既存のセキュリティの弱点の組合を継承します。組み合わせて、彼らは他のキープロトコルに固有ではない、新たな弱点を生成しない限り、これらの弱点に対処する必要はありません。
Acknowledgments
謝辞
The original KINK Kabal was:
元KINK Kabalされました：
Michael Thomas (Cisco) David McGrew (Cisco) Jan Vilhuber (Cisco) Jonathan Trostle (Cisco) Matt Hur (Cybersafe) Mike Froh (Cybersafe) Sasha Medvinsky (GI) Derek Atkins (Telcordia)
マイケル・トーマス（シスコ）デビッドマグリュー（シスコ）月Vilhuber（シスコ）ジョナサンTrostle（シスコ）マット・ハー（のCybersafe）マイク・FROH（のCybersafe）サーシャMedvinsky（GI）デレク・アトキンス（のTelcordia）
It must also be acknowledged that the Packetcable Security specification PKT-SP-SEC-I01-991201 provided the raw fodder for this effort in its Kerberized IPsec section, and all of the focus team members who played a part in the spec. We must also acknowledge Nancy Davoust of Cablelabs for keeping order in our normally disorderly proceedings.
また、PacketCableのセキュリティ仕様PKT-SP-SEC-I01-991201は生のKerberos対応IPsecのセクションでは、この努力のための飼料、および仕様で役割を果たしフォーカスチームのメンバーのすべてを提供することを認めなければなりません。また、当社の通常の無秩序な手続きの順序を維持するためのCableLabsののナンシーDavoustを確認する必要があります。
References
リファレンス
[1] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[1]コールズ、J.及びC.ノイマン、 "ケルベロスネットワーク認証サービス（V5）"、RFC 1510、1993年9月。
[2] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[2]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[3] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[3]ハーキンズ、D.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
Author's Address
著者のアドレス
Michael Thomas Cisco Systems 375 E Tasman Rd San Jose, Ca, 95134, USA
マイケル・トーマスシスコシステムズ375 EタスマンRdのカリフォルニア州サンノゼ、95134、USA
Phone: +1 408-525-5386 EMail: mat@cisco.com
電話：+1 408-525-5386電子メール：mat@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。