draft-ietf-kink-reqmt-01.txt		draft-ietf-kink-reqmt-02.txt
	INTERNET-DRAFT KINK Requirements Michael Thomas		INTERNET-DRAFT KINK Requirements Michael Thomas
	Cisco Systems		Cisco Systems
	January 31, 2001		March 1, 2001
	Kerberized Internet Negotiation of Keys		Kerberized Internet Negotiation of Keys
	draft-ietf-kink-reqmt-01.txt		draft-ietf-kink-reqmt-02.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 3, line 39		skipping to change at page 3, line 39
	Requirements		Requirements
	KINK must meet the following requirements at a minimum:		KINK must meet the following requirements at a minimum:
	- The protocol must use the session keys found in Kerberos tickets as		- The protocol must use the session keys found in Kerberos tickets as
	the basis of the keying material used for IPsec security associa-		the basis of the keying material used for IPsec security associa-
	tion keys.		tion keys.
	- The protocol must be able to integrate into security architecture		- The protocol must be able to integrate into security architecture
	of IPSec (RFC 2401)		of IPsec (RFC 2401)
	- The protocol must be able to start up SA's regardless of any		- The protocol must be able to start up SA's regardless of any
	client/server disposition in the keying protocol. In other words,		client/server disposition in the keying protocol. In other words,
	either IPSec peer can be the initiator or responder, regardless of		either IPsec peer can be the initiator or responder, regardless of
	whether it's a Kerberos 'client' (TGT-only) or Kerberos		whether it's a Kerberos 'client' (TGT-only) or Kerberos 'server'
			(has a keytab).
	- The protocol must be able to initially authenticate using either		- The protocol must support Kerberos using either secret key, or pub-
	secret key, or public key authentication.		lic key (PKINIT) initial authentication.
	- The protocol must support Kerberos User-to-User mode for cases in		- 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.		which the initiator cannot obtain an AP_REQ for the responder (i.e.
	the responder is a PKINIT client) or the responder cannot decrypt		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		and AP_REQ from the initiator (i.e. the responder doesn't have a
	Kerberos Keytab, just a TGT).		Kerberos Keytab, just a TGT).
	- The protocol must be able to allow a peer to authenticate and par-		- The protocol must be able to allow a peer to authenticate and par-
	ticipate in many realms		ticipate in many realms
	- The protocol must handle absolute time skew gracefully		- The protocol must handle absolute time skew gracefully
	- The protocol must be able to create, modify, rekey, and delete		- The protocol must be able to create, modify, rekey, and delete
	security associations		security associations
	- The protocol must be capable of setting up both transport and tun-		- The protocol must be capable of setting up both transport and tun-
	nel modes of IPSec		nel modes of IPsec
	- The protocol must be capable of setting up both AH and ESP security		- The protocol must be capable of setting up both AH and ESP security
	associations		associations
	- The protocol must be capable of negotiating cipher suites		- 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 setting up IPsec flow selectors
	- 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
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/