RFC 3129 (rfc3129) - Page 2 of 6
Requirements for Kerberized Internet Negotiation of Keys
Alternative Format: Original Text Document
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
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 (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
Thomas Informational