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/