Subject: Editorial fixes for KINK Requirements

From: Derek Atkins <[email-masked]>
Date: 01 Mar 2001 09:46:58 -0500

Mike,

Here are some "diffs" against the requirements draft (-01).  The
changes I made are:

	* spelling corrections
	* remove extra blank lines
	* fix a requirement that ends abruptly
	* re-word the 'initial authentication' requirement so it is
	  clear we mean 'initial kerberos authentication'

Can you apply this patch?  If this patch isn't clear (it's a UNIX
context diff), I can send it in another form or just send you my
modified text.  Let me know which you prefer.

-derek

*** draft-ietf-kink-reqmt-01.txt~	Thu Mar  1 09:32:57 2001
--- draft-ietf-kink-reqmt-01.txt	Thu Mar  1 09:41:17 2001
***************
*** 157,174 ****
       the basis of the keying material used for IPsec security associa-
       tion keys.
  
- 
  -    The protocol must be able to integrate into security architecture
!      of IPSec (RFC 2401)
  
  -    The protocol must be able to start up SA's regardless of any
       client/server disposition in the keying protocol. In other words,
!      either IPSec peer can be the initiator or responder, regardless of
!      whether it's a Kerberos 'client' (TGT-only) or Kerberos
! 
  
! -    The protocol must be able to initially authenticate using either
!      secret key, or public key authentication.
  
  -    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.
--- 157,173 ----
       the basis of the keying material used for IPsec security associa-
       tion keys.
  
  -    The protocol must be able to integrate into security architecture
!      of IPsec (RFC 2401)
  
  -    The protocol must be able to start up SA's regardless of any
       client/server disposition in the keying protocol. In other words,
!      either IPsec peer can be the initiator or responder, regardless of
!      whether it's a Kerberos 'client' (TGT-only) or Kerberos 'server'
!      (has a keytab).
  
! -    The protocol must support Kerberos using either secret key or
!      public key (PKINIT) initial authentication.
  
  -    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.
***************
*** 185,191 ****

       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-
--- 184,190 ----

       the responder is a PKINIT client) or the responder cannot decrypt
!      and AP_REQ from the initiator (i.e. the responder doesn't have a
       Kerberos Keytab, just a TGT).
  
  -    The protocol must be able to allow a peer to authenticate and par-
***************
*** 197,203 ****
       security associations
  
  -    The protocol must be capable of setting up both transport and tun-
!      nel modes of IPSec
  
  -    The protocol must be capable of setting up both AH and ESP security
       associations
--- 196,202 ----
       security associations
  
  -    The protocol must be capable of setting up both transport and tun-
!      nel modes of IPsec
  
  -    The protocol must be capable of setting up both AH and ESP security
       associations

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available