draft-ietf-kink-reqmt-02.txt		draft-ietf-kink-reqmt-03.txt
	INTERNET-DRAFT KINK Requirements Michael Thomas
	Cisco Systems
	March 1, 2001
	Kerberized Internet Negotiation of Keys		INTERNET-DRAFT Requirements for Kerberized Michael Thomas
			Internet Negotiation of Keys Cisco Systems
			April 30, 2001
	draft-ietf-kink-reqmt-02.txt		Requirements for Kerberized Internet Negotiation of Keys
			draft-ietf-kink-reqmt-03.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026. Internet-Drafts are working		all provisions of Section 10 of RFC2026. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and its working groups. Note that other groups may also distribute		and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	skipping to change at page 4, line 34		skipping to change at page 4, line 34
	- The protocol must be capable of rekeying without the assistance of		- The protocol must be capable of rekeying without the assistance of
	the KDC if the Kerberos 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		- The protocol must make an effort to mitigate third party Denial of
	Service attacks (aka Zombies attacks)		Service attacks (aka Zombies attacks)
	- The protocol must be able to be used for more than IPsec keying		- The protocol must be able to be used for more than IPsec keying
	- The protocol must support both IPv4 and IPv6		- The protocol must support both IPv4 and IPv6
			Security Considerations
			These requirements lay out input to define a protocol which allows
			the keying of IPsec security associations using Kerberos as the key
			distribution mechanism. As such, the security associations that
			will be created by the new protocol will inherit the union of IPsec
			and Kerberos's existing security weaknesses. There is no require-
			ment to address those weaknesses unless in combination they produce
			a new weakness which is not inherent in other keying protocols.
	Acknowledgments		Acknowledgments
	The original KINK Kabal was:		The original KINK Kabal was:
	Michael Thomas (Cisco)		Michael Thomas (Cisco)
	David McGrew (Cisco)		David McGrew (Cisco)
	Jan Vilhuber (Cisco)		Jan Vilhuber (Cisco)
	Jonathan Trostle (Cisco)		Jonathan Trostle (Cisco)
	Matt Hur (Cybersafe)		Matt Hur (Cybersafe)
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/