RFC3129 日本語訳

Network Working Group                                          M. Thomas
Request for Comments: 3129                                 Cisco Systems
Category: Informational                                        June 2001

コメントを求めるワーキンググループM.トーマスの要求をネットワークでつないでください: 3129年のシスコシステムズカテゴリ: 情報の2001年6月

        Requirements for Kerberized Internet Negotiation of Keys

キーのKerberizedインターネット交渉のための要件

Status of this Memo

この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.

Copyright(C)インターネット協会(2001)。 All rights reserved。

Abstract

要約

   The goal of this document is to produce a streamlined, fast, easily
   managed, and cryptographically sound protocol without requiring
   public key.

このドキュメントの目標は、速く容易に管理されていた状態で合理化されるaを生産して、暗号で公開鍵を必要としないでプロトコルを鳴らすことです。

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ワーキンググループは層three(すなわち、IP層)で暗号で安全なセキュリティ協会を創設して、維持する能力を提供する多くのプロトコルを定義しました。 この取り組みは2つの異なったプロトコルを作成しました:

   1) a mechanism to encrypt and authenticate IP datagram payloads which
      assumes a shared secret between the sender and receiver

1) 送付者と受信機の間の共有秘密キーを仮定するIPデータグラムペイロードを暗号化して、認証するメカニズム

   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

ピアツーピア認証とメカニズムを合わせるIKE(RFC2409)をIPsecワーキンググループは定義しました。 ピアツーピアプロトコルの欠点の1つは各同輩がサイトの実際にはかなり複雑である場合がある安全保障政策を知って、実装しなければならないということです。 さらに、信頼できる第三者機関の不足は、共有秘密キーを証明するためにディフィー・ヘルマン(DH)の使用を必要とします。 残念ながら、DHはサービス不能攻撃に計算上かなり高価であって、傾向があります。 また、IKEは、同輩のスケーラブルな認証がわかるためにX.509証明書を当てにします。 デジタル署名は計算上も高価で証明書に基づいている信頼モデルは配布するのが難しいということです。

Thomas                       Informational                      [Page 1]

RFC 3129                 Requirements for KINK                 June 2001

もつれ2001年6月のためのトーマス情報[1ページ]のRFC3129Requirements

   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.

実際には。 IKEがあらかじめ共有された対称鍵を考慮している間、主要な分配がすべての同輩の間で必要です--O(n^2)問題(大きい展開に問題が多いです)。

   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.

(RFC1510)がクライアントとサーバのための信頼できる第三者機関認証のためのメカニズムを提供するケルベロス。 クライアントはクライアントがそれが主張する人であると立証しながら順番に、その結果サーバが解読することができるチケットを発行するものを集結されたサーバ(Key Distributionセンター)に認証します。 ケルベロスチケットの要素の1つはクライアントとサーバによって使用される、秘密を共有するかもしれないKDCによって生成されるセッションキーです。 また、ケルベロスは対称鍵認証と証明書の両方のために、ベースの公開鍵認証(PKinit)を許します。 ケルベロスの認証フェーズがKDCによって実行されるので、高価なDHかX.509証明書署名/検証操作をサーバに実行する必要は全くありません。 クライアントが使用を認証しているかもしれない間、X.509証明書であり、資格証明書の生涯認証フェーズを清算できます。 これは、独身のDHと証明書交換が計算上経済の方法で多くのサーバとの主要なセキュリティ協会に使用されるのを許容します。 また、ケルベロスは対称鍵でクライアントをサポートしますが、IKEと異なって、対称鍵は、キーの数をO(n^2)よりむしろO(n)問題にしながら、KDCに保存されます。 また、ケルベロスは、それぞれの潜在的に信頼できない同輩が組織の述べられた安全保障政策を守ると予想するより安全保障政策がさらに集結されたファッションでむしろ管理されるのを許容します。

   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ワーキンググループは、ケルベロスに関するこれらの基本的特徴を取って、IPsecセキュリティ協会(RFC2401)を設立して、維持できるプロトコルを作成する利点にそれらを使用します。 KINKがIKEへの交換品でないことに注意されるべきです。 IKEには、KINKが再生させることができない1つの特性があります: 2のための能力は、活発に参加している第三者の必要性なしでキーを互いに認証して、交換するためにじっと見ます。 しかしながら、多くの状況がaがそれのプロキシ認証が実行可能であって、事実上望ましい第三者を信じたところにあります。

   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.

ケルベロスはチケットを手に入れるためにクライアントと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

上記を考えて、ケルベロスのスケーラビリティを利用するプロトコルを合わせる新しい司令官は望ましいです。 最初のタスクがこのプロトコルを定義して、解釈のドメインを定義することになっているワーキンググループのもの

Thomas                       Informational                      [Page 2]

RFC 3129                 Requirements for KINK                 June 2001

もつれ2001年6月のためのトーマス情報[2ページ]のRFC3129Requirements

   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。 RFC2401の特徴を最大限に利用できますが、プロトコルは集結された合わせる権威の文脈でそうしなければなりません。

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セキュリティ協会キーに使用した合わせることの基礎としてケルベロスチケットの中に見つけられたセッションキーを使用しなければなりません。

   -     The protocol must be able to integrate into security
         architecture of IPsec (RFC 2401).

- プロトコルはIPsec(RFC2401)のセキュリティー体系と統合できなければなりません。

   -     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専用)かケルベロス'サーバ'(keytabを持っている)であることにかかわらず。

   -     The protocol must support Kerberos using either secret key, or
         public key (PKINIT) initial authentication.

- プロトコルは、秘密鍵か公開鍵(PKINIT)の初期の認証のどちらかを使用することでケルベロスをサポートしなければなりません。

   -     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クライアントである)か応答者のためのREQが解読することができないAP_とAP_REQを入手できない場合のためのUserからユーザ・モードであるとサポートしなければなりません(すなわち、応答者はケルベロスKeytabを持っていません、まさしく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.

- プロトコルは、セキュリティ協会を作成して、変更して、rekeyして、削除できなければなりません。

   -     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と超能力セキュリティ協会の両方を設立できなければなりません。

   -     The protocol must be capable of negotiating cipher suites.

- プロトコルは暗号スイートを交渉できなければなりません。

   -     The protocol must be capable of setting up IPsec flow
         selectors.

- プロトコルはIPsec流れセレクタをセットアップできなければなりません。

Thomas                       Informational                      [Page 3]

RFC 3129                 Requirements for KINK                 June 2001

もつれ2001年6月のためのトーマス情報[3ページ]のRFC3129Requirements

   -     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).

- プロトコルは、第三者サービス妨害攻撃(別名Zombies攻撃)を緩和するために取り組みを作らなければなりません。

   -     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.

これらの要件は、主要な分配メカニズムとしてケルベロスを使用することでIPsecセキュリティ協会を合わせることを許すプロトコルを定義するために入力を広げます。 そういうものとして、新しいプロトコルによって創設されるセキュリティ協会はIPsecとケルベロスの既存のセキュリティ弱点の組合を引き継ぐでしょう。 組み合わせでは、他の合わせるプロトコルに固有でない新しい弱点を生産しない場合、それらの弱点を扱うという要件が全くありません。

Acknowledgments

承認

   The original KINK Kabal was:

オリジナルのKINKカバルは以下の通りでした。

      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(シスコ)マットHur(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 Security仕様PKT-SP SEC I01-991201が仕様で役を務めたKerberized IPsec部のこの取り組み、および焦点のチームメンバーに皆、生のまぐさを提供したと認めなければなりません。 また、私たちがオーダーに閉じ込めるためにCablelabsのナンシーDavoustを承認しなければならない、私たち、通常無秩序な議事。

Thomas                       Informational                      [Page 4]

RFC 3129                 Requirements for KINK                 June 2001

もつれ2001年6月のためのトーマス情報[4ページ]のRFC3129Requirements

References

参照

   [1]  Kohl, J. and C. Neuman, "The Kerberos Network
        Authentication Service (V5)", RFC 1510, September 1993.

[1] コールとJ.とC.ヌーマン、「ケルベロスネットワーク認証サービス(V5)」、RFC1510 1993年9月。

   [2]  Kent, S. and R. Atkinson, "Security Architecture for the
        Internet Protocol", RFC 2401, November 1998.

[2] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。

   [3]  Harkins, D. and D. Carrel, "The Internet Key
        Exchange (IKE)", RFC 2409, November 1998.

[3] ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。

Author's Address

作者のアドレス

   Michael Thomas
   Cisco Systems
   375 E Tasman Rd
   San Jose, Ca, 95134, USA

375Eのマイケル・トーマス・シスコシステムズタスマン・第サンノゼ、Ca、95134、米国

   Phone: +1 408-525-5386
   EMail: mat@cisco.com

以下に電話をしてください。 +1 408-525-5386 メールしてください: mat@cisco.com

Thomas                       Informational                      [Page 5]

RFC 3129                 Requirements for KINK                 June 2001

もつれ2001年6月のためのトーマス情報[5ページ]のRFC3129Requirements

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Copyright(C)インターネット協会(2001)。 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機能のための基金は現在、インターネット協会によって提供されます。

Thomas                       Informational                      [Page 6]

トーマスInformationalです。[6ページ]