[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: (draft-thomas-kink-reqmt) 00 01 02
03 RFC 3129
INTERNET-DRAFT KINK Requirements Michael Thomas
Cisco Systems
August 9, 2000
Kerberized Internet Negotiation of Keys
draft-ietf-kink-reqmt-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 management for IPsec security
associations as defined in RFC 2401, as an alternative to IKE (RFC
2409). Participating systems will use the Kerberos architecture as
defined in RFC 1510 (and its successors) for key management. The goal
of the working group is to produce a streamlined, fast, easily
managed, and cryptographically sound protocol without requiring
public key.
The working group will not require changes to either IPsec (RFC
2401), or Kerberos (RFC 1510).
Thomas draft-ietf-kink-reqmt-00 [Page 1]
INTERNET-DRAFT Kerberized Internet Negotiation of Keys 9 August 2000
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:
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 computation-
ally 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 cer-
tificate 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 prob-
lematic 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 authen-
tication 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 secu-
rity 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.
Thomas draft-ietf-kink-reqmt-00 [Page 2]
INTERNET-DRAFT Kerberized Internet Negotiation of Keys 9 August 2000
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 par-
ticipating 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 alterna-
tive to requiring each application having its own method of tran-
sporting 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 pro-
tocol 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
Thomas draft-ietf-kink-reqmt-00 [Page 3]
INTERNET-DRAFT Kerberized Internet Negotiation of Keys 9 August 2000
- The protocol must be able to allow a peer to authenticate and par-
ticipate 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 tun-
nel 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
Sep 2000 Consensus on requirements document
Dec 2000 Review drafts at Dec IETF
Thomas draft-ietf-kink-reqmt-00 [Page 4]
INTERNET-DRAFT Kerberized Internet Negotiation of Keys 9 August 2000
Jan 2001 Consensus on base draft protocol
Mar 2001 WG Last call on draft
Mar 2001-Jun 2001
Interoperability Bakeoffs
Aug 2001 Interoperability results, decision to recycle or move for-
ward
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: ietf-kink@vpnc.org
To Subscribe: majordomo@vpnc.org
In Body: in body: subscribe ietf-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)
Thomas draft-ietf-kink-reqmt-00 [Page 5]
INTERNET-DRAFT Kerberized Internet Negotiation of Keys 9 August 2000
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
[1] The CAT Working Group, J. Kohl, C.Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993
[2] The IPsec Working Group, S. Kent, R. Atkinson, "Security Architec-
ture for the Internet Protocol", RFC 2401, November 1998
[3] 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
Thomas draft-ietf-kink-reqmt-00 [Page 6]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/