米葫芦网

RFC3129 - Requirements for Kerberized Internet Negotiation of Keys

热度:4℃ 发布时间:2023-11-16 19:56:48

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.
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:
1) a mechanism to encrypt and authenticate IP datagram payloads which
assumes a shared secret between the sender and receiver
2) a mechanism for IPsec peers to perform mutual authentication and
exchange keying material
The IPsec working group has defined a peer to peer authentication and
keying mechanism, IKE (RFC2409). 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.
Kerberos (RFC1510) 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.
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 (RFC2401). 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.
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.
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.
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.
- The protocol must be able to integrate into security
architecture of 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).
- The protocol must support Kerberos using either secret key, or
public key (PKINIT) initial authentication.
- 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).
- 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.
- The protocol must be capable of setting up both AH and ESP
security associations.
- The protocol must be capable of negotiating cipher suites.
- The protocol must be capable of setting up IPsec flow
selectors.
- The protocol must be capable of rekeying without the assistance
of the KDC if the Kerberos session ticket is still valid.
- 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.
- The protocol must support both IPv4 and 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.
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)
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.
References
[1] Kohl, J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC1510, September 1993.
[2] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC2401, November 1998.
[3] Harkins, D. and D. Carrel, "The Internet Key
Exchange (IKE)", RFC2409, November 1998.
Author"s Address
Michael Thomas
Cisco Systems
375 E Tasman Rd
San Jose, Ca, 95134, USA
Phone: +1 408-525-5386
EMail: mat@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (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.
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 RFCEditor function is currently provided by the
Internet Society.

网友评论
评论
发 布

更多软件教程
  • 软件教程推荐
更多+
Greenfoot设置中文的方法

Greenfoot设置中文的方法

Greenfoot是一款简单易用的Java开发环境,该软件界面清爽简约,既可以作为一个开发框使用,也能够作为集成开发环境使用,操作起来十分简单。这款软件支持多种语言,但是默认的语言是英文,因此将该软件下载到电脑上的时候,会发现软件的界面语言是英文版本的,这对于英语基础较差的朋友来说,使用这款软件就会...

07-05

Egret UI Editor修改快捷键的方法

Egret UI Editor修改快捷键的方法

Egret UI Editor是一款开源的2D游戏开发代码编辑软件,其主要功能是针对Egret项目中的Exml皮肤文件进行可视化编辑,功能十分强大。我们在使用这款软件的过程中,可以将一些常用操作设置快捷键,这样就可以简化编程,从而提高代码编辑的工作效率。但是这款软件在日常生活中使用得不多,并且专业性...

07-05

KittenCode新建项目的方法

KittenCode新建项目的方法

KittenCode是一款十分专业的编程软件,该软件给用户提供了可视化的操作界面,支持Python语言的编程开发以及第三方库管理,并且提供了很多实用的工具,功能十分强大。我们在使用这款软件进行编程开发的过程中,最基本、最常做的操作就是新建项目,因此我们很有必要掌握新建项目的方法。但是这款软件的专业性...

07-05

Thonny设置中文的方法

Thonny设置中文的方法

Thonny是一款十分专业的Python编辑软件,该软件界面清爽简单,给用户提供了丰富的编程工具,具备代码补全、语法错误显示等功能,非常的适合新手使用。该软件还支持多种语言,所以在下载这款软件的时候,有时候下载到电脑中的软件是英文版本的,这对于英语基础较差的小伙伴来说,使用这款软件就会变得十分困难,...

07-05

最新软件下载