discuss on draft-ietf-kink-kink-05.txt

[Randy Bush <randy@psg.com>]

if there is to be kerberos sales literature

   The central key management provided by Kerberos is efficient because
   it limits computational cost and limits complexity versus IKE's
   necessity of using public key cryptography.  Initial authentication
   to the KDC may be performed using either symmetric keys or asymmetric
   keys using [PKINIT]; however, subsequent requests for tickets, as
   well as authenticated exchanges between client and server always
   utilize symmetric cryptography. Therefore, public key operations (if
   any) are limited and are amortized over the lifetime of the initial
   authentication operation to the Kerberos KDC. For example, a client
   may use a single public key exchange with the KDC to efficiently
   establish multiple security associations with many other servers in
   the extended realm of the KDC. Kerberos also scales better than
   direct peer to peer keying when symmetric keys are used. The reason
   is that since the keys are stored in the KDC, the number of principal
   keys is O(n) rather than O(n*m), where "n" is the number of clients
   and "m" is the number of servers.

it might also mention the vulnerabilities of centralized key
service, and kerberos's other issues.  [ note that i did love and
use the dawg for many years, but in the multi-organization
internet, it just did not scale to meet my needs ]

---

i am confused by the first clause in

   Note: if B adds a nonce, or does not choose the first proposal, it
   MUST request an ACK so that it can install the final outbound secu-
   rity association.  The initiator MUST always generate an ACK if the
   ACKREQ bit is set in the KINK header, even if it believes that the
   respondent was in error.

because, if B does not choose the first proposal, B MUST add a
nonce. 

---

   delete the incoming SA. For simplicity, KINK does not allow half open
   security associations; thus upon receiving a DELETE, the responder
   MUST delete its security associations, and MUST reply with ISAKMP
   delete notification messages if the SPI is found.

or ISAKMP INVALID_SPI if it is not

---

   Normally a KINK implementation which rekeys existing security associ-
   ations will try to rekey the security association ahead of a hard SA
   expiration. We call this time the rekey time Trekey. In order to
   avoid synchronization with similar implementations, KINK initiators
   MUST randomly pick a rekeying time between Trekey and the SA expira-
   tion time minus the amount of time it would take to go through a full
   retransmission time cycle, Tretrans. Trk SHOULD be set at least twice
   as high as Tretrans.                 ^^^

what is Trk?  (hint: it is nowhere else in the document).  likely
TReKey is ment (and yes, i wish they had used smalltalkish caps)

---

i gota ask.  why the heck is the payload type of payload N encoded
as data in payload N-1 (or the header when N=1)?  this is just too
kinky for me.  if there is an actual reason, at least explain it.

i mean what the heck, why not have the length of payload N be in
payload N-1 so at least things are consistent? </sarcasm>

yes, i realize that making N tell its own type would mean that
KINK_DONE would have to become something like KINK_LAST.  so what?

---

KINK proudly uses UDP.  will it's data always fit in MTU?

---

maybe a sec cons ref to some kerberos sec cons reviews would be
useful.

---

no iana considerations for registering future
   Payload Types
   NOTIFY ERROR TYPES
   KINK_ERROR Payload
are appropriate?

---

nits:

draft uses end of line hypenation

draft occasionally uses right margin juustification

i know i am not supposed to whine about these, but they make it
hard to read, darn it.

-

redefinition of all the canine terms such as ticket, kdc, etc. may
leave one open to definitional differences.  i guess it's a hard
call on how much to bring over.

-
   KINK uses Kerberos mechanisms to provide mutual authentication,
   replay protection.

gramur.  prolly want to s/,/and/

-
   The  initiator  MUST  checks  to  see  if  the optimistic payload was
                              ^
-

   The DELETE command deletes an existing security association.  The DOI
   specific  payloads  describe  the  actual  security association to be
   deleted. For the IPSEC DOI, those payloads  will  include  an  ISAKMP
   payload contains the SPI to be deleted in each direction.

s/contains/containing/
     or
s/contains/which contains/

-
   In order to determine that a KINK peer has lost its security database
   information, KINK peers MUST record the current epoch for which they
   have valid SADB information

no definition of SADB in document, though it is occasionally
hinted.

-

lack of consistency in field explanations, e.g. in

5.1.5.  KINK_TGT_REQ Payload, RESERVED is defined, while in
5.1.6.  KINK_TGT_REP Payload, it is not

and field explanations are often not in the same order as the
fields in the payload.  and the explanations often do not use
consistent typography, e.g. in 5.1.7.  KINK_ISAKMP Payload.

-

   The Nonce payload contains random data  that  MUST  be  used  in  key
   generation  by  the  initiating  KINK  peer,  and  MAY be used by the
   responding KINK peer.  See section 8 for the discussion of their  use
   in key generation.

s/thier/its/

-

randy