Browse Prior Art Database

Requirements for Kerberized Internet Negotiation of Keys (RFC3129)

IP.com Disclosure Number: IPCOM000005313D
Original Publication Date: 2001-Jun-01
Included in the Prior Art Database: 2001-Aug-21
Document File: 7 page(s) / 11K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

M. Thomas: AUTHOR

Abstract

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

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 29% of the total text.

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