One document matched: draft-thomas-kink-charter-00.txt

INTERNET-DRAFT      KINK Charter          Michael Thomas
                                          Cisco Systems
                                          June 26, 2000






                Kerberized Internet Negotiation of Keys

                    draft-thomas-kink-charter-00.txt



Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   The KINK working group is chartered to create a standards track
   protocol to facilitate centralized key exchange in an application
   independent fashion. Participating systems will use the Kerberos
   architecture as defined in RFC 1510 for key management and the KINK
   protocol between applications. The goal of the working group is to
   produce a low latency, computationally efficient, easily managed, and
   cryptographically sound protocol that is flexible enough to be able
   to be extended for many applications.

   The focus of the initial working group will be keying IPsec security
   associations as defined in RFC 2401. The working group may consider
   means to key other protocols in the future, but the initial goal of
   the KINK working group is specifically targeted at producing a low
   latency and computationally efficient keying mechanism for IPsec. The
   working group will not be involved with, nor should it require
   changes to either IPsec (RFC 2401), or Kerberos (RFC 1510).

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 (ie, the IP layer).  This effort
   has produced two distinct protocols:  a mechanism to encrypt and
   authenticate IP datagram payloads which assumes a shared secret
   between the sender and receiver 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
   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
   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 Kerberos to create session keys in a secure fashion The
   protocol must be able to integrate into security architecture of
   IPSec (RFC 2401) The protocol must be able to start up SA's
   regardless of any client/server disposition in the keying protocol
   Kerberos makes a distinction between clients and servers; IPsec does
   not. The protocol must allow for IPsec security associations to be
   initiated by both servers and clients, thus preserving IPsec's peer
   to peer nature.  The protocol must be able to initially authenticate
   using either secret key, or public key authentication.  The protocol
   must accommodate any combination of public and secret key peers 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 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


Deliverables

   The working group's responsibilities are as follows:
   Complete a protocol which meets the requirements outlined above Keep
   all KINK working group documents moving along publication /
   standardization track.
   The list of the working group's current work items is as follows:
   Define the base Kerberized Internet Negotiation of Keys protocol.

Goals and Milestones
   Hold BOF, create KINK working group, present candidates for base
   protocol, administrativa Consensus on the candidate draft for the
   working group Review working group draft of KINK, determine level of
   consensus to move toward WG last call, incorporate review comment WG
   last call on KINK protocol Interoperability bake offs
   Interoperability results, decision to recycle or move toward draft
   standard
Administrativa

Chair(s):

  Derek Atkins <warlord@research.telcordia.com>

Document Editor:

  TBD

Internet Area Director(s):

  Jeffrey Schiller <jis@mit.edu>
  Marcus Leech <mleech@nortelnetworks.com>

Internet Area Advisor:

TBD

Mailing Lists:

  General Discussion: kink@external.cisco.com
  To Subscribe: mailer@cisco.com
  In Body: in body: subscribe kink
  Archive: ftp://

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
   The CAT Working Group, J. Kohl, C.Neuman, "The Kerberos Network
   Authentication Service (V5)", RFC 1510, September 1993
   The IPsec Working Group, S. Kent, R. Atkinson, "Security Architecture
   for the Internet Protocol", RFC 2401, November 1998
   The IPsec Working Group, D. Harkins, D. Carrel, "The Internet Key
   Exchange", RFC 2409, November 1998

Author's Address

          Michael Thomas
          Cisco Systems
          375 E Tasman Rd
          San Jose, Ca, 95134, USA
          Tel: +1 408-525-5386
          E-MAIL: mat@cisco.com