--- 1/draft-ietf-kink-reqmt-00.txt 2006-02-05 00:06:32.000000000 +0100 +++ 2/draft-ietf-kink-reqmt-01.txt 2006-02-05 00:06:32.000000000 +0100 @@ -1,18 +1,18 @@ INTERNET-DRAFT KINK Requirements Michael Thomas Cisco Systems - August 9, 2000 + January 31, 2001 Kerberized Internet Negotiation of Keys - draft-ietf-kink-reqmt-00.txt + draft-ietf-kink-reqmt-01.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 @@ -111,122 +111,70 @@ 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 use the session keys found in Kerberos tickets as + the basis of the keying material used for IPsec security associa- + tion keys. - 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. + client/server disposition in the keying protocol. In other words, + either IPSec peer can be the initiator or responder, regardless of + whether it's a Kerberos 'client' (TGT-only) or Kerberos - 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 support Kerberos User-to-User mode for cases in + which the initiator cannot obtain an AP_REQ for the responder (i.e. + + the responder is a PKINIT client) or the responder cannot decrypt + and AP_REQ from the initiator (i.e. the ressponder doesn't have a + Kerberos Keytab, just a TGT). - 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 KDC if the Kerberos 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 - -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 - -Document Editor: - - TBD - -Internet Area Director(s): - - Jeffrey Schiller - Marcus Leech - -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)