draft-ietf-kink-reqmt-00.txt   draft-ietf-kink-reqmt-01.txt 
INTERNET-DRAFT KINK Requirements Michael Thomas INTERNET-DRAFT KINK Requirements Michael Thomas
Cisco Systems Cisco Systems
August 9, 2000 January 31, 2001
Kerberized Internet Negotiation of Keys Kerberized Internet Negotiation of Keys
draft-ietf-kink-reqmt-00.txt draft-ietf-kink-reqmt-01.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 34 skipping to change at page 3, line 34
scalability of Kerberos is desirable. The working group's first task scalability of Kerberos is desirable. The working group's first task
is to define this protocol and define an domain of interpretation for is to define this protocol and define an domain of interpretation for
IPsec to establish and maintain IPsec security associations. The pro- IPsec to establish and maintain IPsec security associations. The pro-
tocol must be able to take full advantage of the features of RFC 2401 tocol must be able to take full advantage of the features of RFC 2401
but in the context of a centralized keying authority. but in the context of a centralized keying authority.
Requirements Requirements
KINK must meet the following requirements at a minimum: KINK must meet the following requirements at a minimum:
- The protocol must use Kerberos to create session keys in a secure - The protocol must use the session keys found in Kerberos tickets as
fashion the basis of the keying material used for IPsec security associa-
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 client/server disposition in the keying protocol. In other words,
either IPSec peer can be the initiator or responder, regardless of
- Kerberos makes a distinction between clients and servers; IPsec whether it's a Kerberos 'client' (TGT-only) or Kerberos
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 - The protocol must be able to initially authenticate using either
secret key, or public key authentication. secret key, or public key authentication.
- The protocol must accommodate any combination of public and secret - The protocol must support Kerberos User-to-User mode for cases in
key peers 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- - 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 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
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 <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 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)
Mike Froh (Cybersafe) Mike Froh (Cybersafe)
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/