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/