Requirements for Kerberized Internet Negotiation of Keys (RFC3129)
Original Publication Date: 2001-Jun-01
Included in the Prior Art Database: 2019-Feb-14
Internet Society Requests For Comment (RFCs)
The goal of this document is to produce a streamlined, fast, easily managed, and cryptographically sound protocol without requiring public key. This memo provides information for the Internet community.
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 (C) The Internet Society (2001). All Rights Reserved.
The goal of this document is to produce a streamlined, fast, easily managed, and cryptographically sound protocol without requiring public key.
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 (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
Thomas Informational [Page 1]
RFC 3129 Requirements for KINK June 2001
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 (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 su...