RFC 3129 - Requirements for Kerberized Internet Negotiation of Keys 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3129
タイトル : RFC 3129 - 鍵のインターネット交渉の要件
翻訳編集 : 自動生成

[要約] RFC 3129は、Kerberosを使用したインターネット上での鍵の交渉に関する要件を定義しています。その目的は、セキュアな通信を確保するために、Kerberosプロトコルを使用して鍵の交換を行うためのガイドラインを提供することです。

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.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。

著作権表示

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

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 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 Hellman（DH）を使用する必要があります。DHは、残念ながら、計算上非常に高価であり、サービス攻撃を拒否する傾向があります。Ikeは、ピアのスケーラブルな認証を実現するためにX.509証明書にも依存しています。デジタル署名も計算的に高価であり、証明書ベースの信頼モデルを実際に展開することは困難です。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.

Kerberos（RFC 1510）は、クライアントとサーバーに信頼できるサードパーティ認証のメカニズムを提供します。クライアントは、主要な配信センターである集中サーバーに認証されます。これにより、サーバーが復号化できるチケットを発行し、クライアントが誰であるかを証明します。Kerberosチケットの要素の1つは、秘密を共有するためにクライアントとサーバーが使用できるKDCによって生成されるセッションキーです。Kerberosは、対称キー認証と証明書ベースの公開キー認証（Pkinit）の両方を許可しています。Kerberosの認証フェーズはKDCによって実行されるため、サーバーで高価なDHまたはX.509証明書の署名/検証操作を実行する必要はありません。クライアントはX.509証明書を使用して認証できますが、認証フェーズは資格情報の寿命にわたって償却できます。これにより、単一のDHと証明書交換を使用して、計算上の経済的な方法で多くのサーバーとの主要なセキュリティ関連の関連付けを行うことができます。Kerberosは対称キーを持つクライアントもサポートしますが、IKEとは異なり、対称キーはKDCに保存され、キーの数はO（n^2）ではなくO（n）問題になります。また、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の代替品ではないことに注意する必要があります。Ikeには、Kinkが再現できない1つのプロパティがあります。2人のピアが積極的に参加するサードパーティを必要とせずに、鍵を相互に認証および交換する能力です。ただし、認証が実行可能であり、実際に望ましい信頼できるサードパーティが多くの状況があります。

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は、効率的でKerberosの特定のニーズに合わせたプロトコルとキーイングとパラメーターのネゴシエーションを提供するアプリケーションに合わせたプロトコルを使用して、サービスチケットを輸送および検証する独自の方法を持つ方法を持つことを要求する代替案であることを目的としています。

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.

上記を考えると、Kerberosのスケーラビリティを活用する新しい一般的なキーイングプロトコルが望ましいです。ワーキンググループの最初のタスクは、このプロトコルを定義し、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を起動できる必要があります。つまり、Kerberosの「クライアント」（TGTのみ）またはKerberosの「サーバー」（キータブを持っている）に関係なく、IPSECピアはイニシエーターまたはレスポンダーになる可能性があります。

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

- プロトコルは、イニシエーターがレスポンダーのAP_REQを取得できない場合（つまり、レスポンダーがPkinitクライアントです）、またはレスポンダーがイニシエーター（すなわち、応答者はnodn donn '' 'TはKerberos 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.

- プロトコルは、セキュリティアソシエーションを作成、変更、再キー、削除できる必要があります。

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

- Kerberosセッションのチケットがまだ有効である場合、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:

元のキンク・カバルは次のとおりです。

Michael Thomas (Cisco) David McGrew (Cisco) Jan Vilhuber (Cisco) Jonathan Trostle (Cisco) Matt Hur (Cybersafe) Mike Froh (Cybersafe) Sasha Medvinsky (GI) Derek Atkins (Telcordia)

マイケル・トーマス（シスコ）デイビッド・マクグリュー（シスコ）ヤン・ヴィルフーバー（シスコ）ジョナサン・トロステル（シスコ）マット・ハー（サイバーフ）マイク・フロー（サイバーアフェ）サーシャ・メドビンスキー（GI）デレク・アトキンス（テルコルディア）

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が、Kerberized IPSECセクションでこの努力のために生の飼料を提供し、スペックに参加したすべてのフォーカスチームメンバーを提供したことも認めなければなりません。また、通常の無秩序な訴訟で秩序を維持してくれたCablelabsのNancy Davousthtを認めなければなりません。

References

参考文献

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

[1] Kohl、J。およびC. Neuman、「The Kerberos Network Authentication Service（V5）」、RFC 1510、1993年9月。

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

[2] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。

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

[3] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。

Author's Address

著者の連絡先

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

マイケル・トーマス・シスコ・システム375 E Tasman Rd San Jose、CA、95134、米国

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

Full Copyright Statement

完全な著作権声明

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エディター機能の資金は現在、インターネット協会によって提供されています。