RFC 3129: Requirements for Kerberized Internet Negotiation of Keys 中文翻译

URL : https://datatracker.ietf.org/doc/html/rfc3129
标题 : RFC 3129
翻译类型 : 自动生成

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

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

Requirements for Kerberized Internet Negotiation of Keys

密钥的Kerberized Internet协商要求

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工作组定义了许多协议，这些协议提供了在第三层（即IP层）创建和维护加密安全安全关联的能力。这项工作产生了两种不同的协议：

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

IPsec工作组定义了对等身份验证和密钥机制IKE（RFC 2409）。对等协议的缺点之一是，每个对等方都必须知道并实现站点的安全策略，这在实践中可能相当复杂。此外，缺少可信的第三方需要使用Diffie-Hellman（DH）来建立共享秘密。不幸的是，DH在计算上非常昂贵，并且容易受到拒绝服务攻击。IKE还依赖X.509证书来实现对等点的可伸缩身份验证。数字签名的计算成本也很高，基于证书的信任模型很难部署

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.

Kerberos（RFC 1510）为客户端和服务器提供了一种可信的第三方身份验证机制。客户机向一个集中的服务器（密钥分发中心）进行身份验证，该服务器反过来会发出票据，服务器可以解密这些票据，从而证明客户机就是它声称的那个客户机。Kerberos票证的一个元素是KDC生成的会话密钥，客户端和服务器可以使用该密钥共享机密。Kerberos还允许对称密钥身份验证和基于证书的公钥身份验证（PKinit）。由于Kerberos的身份验证阶段由KDC执行，因此不需要在服务器上执行昂贵的DH或X.509证书签名/验证操作。虽然客户端可以使用X.509证书进行身份验证，但身份验证阶段可以在凭据的整个生命周期内分期进行。这允许使用单个DH和证书交换以计算经济的方式为多个服务器的安全关联设置密钥。Kerberos还支持具有对称密钥的客户端，但与IKE不同，对称密钥存储在KDC中，使得密钥数量成为O（n）问题，而不是O（n^2）。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）。应该注意的是，扭结并不是IKE的替代品。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是一种替代方案，要求每个应用程序都有自己的传输和验证服务票证的方法，使用一种高效的协议，并根据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

鉴于上述情况，需要一种利用Kerberos可伸缩性的新的通用密钥协议。工作组的第一项任务是确定这项议定书，并为其定义一个解释领域

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:

扭结必须至少满足以下要求：

- The protocol must use the session keys found in Kerberos tickets as the basis of the keying material used for IPsec security association keys.

- 协议必须使用Kerberos票据中的会话密钥作为IPsec安全关联密钥所用密钥材料的基础。

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

- 协议必须支持Kerberos用户对用户模式，以防发起方无法获得响应方的AP_请求（即，响应方是PKINIT客户端）或响应方无法从发起方解密和AP_请求（即，响应方没有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.

- 如果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:

最初的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)

迈克尔·托马斯（思科公司）大卫·麦格雷夫（思科公司）扬·维尔胡伯（思科公司）乔纳森·特罗斯特勒（思科公司）马特·休尔（网络安全公司）迈克·弗罗（网络安全公司）萨沙·梅德文斯基（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 Davoust在我们通常无序的程序中维护了秩序。

References

工具书类

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

[1] Kohl，J.和C.Neuman，“Kerberos网络身份验证服务（V5）”，RFC15101993年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，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。

Author's Address

作者地址

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

美国加利福尼亚州圣何塞塔斯曼东路375号迈克尔·托马斯·思科系统公司，邮编95134

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

   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编辑功能的资金目前由互联网协会提供。