Requirements for Kerberized Internet Negotiation of Keys
RFC 3129

Document Type RFC - Informational (June 2001; No errata)
Author Michael Thomas 
Last updated 2013-03-02
Stream Internent Engineering Task Force (IETF)
Formats plain text html pdf htmlized (tools) htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3129 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
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.


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

   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.

   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
Show full document text