Kerberized Internet Negotiation of Keys (KINK)
RFC 4430

Note: This ballot was opened for revision 11 and is now closed.

(Scott Bradner) Discuss

Discuss (2005-08-18)
                 at 36 pages this doc should have a table of contents
                 this can be done with an RFC Ed note if there are no
                 other reasons to spin the ID

(Steven Bellovin) Yes

(Sam Hartman) Yes

(Jeffrey Schiller) Yes

(Harald Alvestrand) No Objection

(Randy Bush) No Objection

(Brian Carpenter) No Objection

Comment (2005-12-13)
No email
send info
A couple of clarity comments on this text:

4.2.7.  KINK_ENCRYPT Payload

   The KINK_ENCRYPT payload encapsulates other payloads and is encrypted
   using the encryption algorithm specified by the etype of the session
   key.  This payload MUST be the final payload in the message.  KINK
   encrypt payloads MUST be encrypted before the final KINK checksum is

Saying that an encapsulating payload is also the final payload
is a little confusing to me, although mathematically correct.
Also, shouldn't the last sentence begin with "KINK_ENCRYPT"
(keyword) rather than "KINK encrypt" (two words)?

Related clarity comments from Gen-ART review by Joel Halpern.

The wording of section 6.1 describing the content of the REPLY message, section 6.3 text describing the CREATE message, the example of the CREATE sequence, and section 4.2.7 on KINK_ENCRYPT are subtly inconsistent.
a) The description of KINK_ENCRYPT should indicate that the inner types are the same as regular KINK types, and that KINK_ENCRYPT is specifically intended to be used as a wrapper around other KINK TLVs.
b) The description of the REPLY and CREATE messages should state that KINK_ENCRYPT is a valid TLV.  The wording lists a set of TLVs that are valid, and does not list KINK_ENCRYPT.

Gen-ART review URL will be

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Ned Freed) No Objection

(Ted Hardie) No Objection

(Scott Hollenbeck) (was Discuss) No Objection

(Russ Housley) No Objection

Comment (2005-12-12)
No email
send info
  Section 1: s/peer to peer/peer-to-peer/

  Section 10: s/perfect forward secrecy/perfect forward secrecy (PFS)/

(Allison Mankin) No Objection

Comment (2005-08-17)
No email
send info
Comment transferred from old style text ballot:

Please convey this to the working group for later consideration:

Yes, the MUST for truncated exponential backoff of retransmission
in the Transport Considerations is critically needed - thanks!

It seems like there might be a lot of retransmission in some 
circumstances - fragments due to long packets...

Could the group consider another transport (future PR-SCTP or a
reliability shim over DCCP, both of which are much more DoS resistant
than TCP) when they think about a later rev with more experience or
when they get ready for Draft Standard?

(Thomas Narten) No Objection

(Jon Peterson) No Objection

(Mark Townsley) No Objection

(Bert Wijnen) No Objection

(Alex Zinin) No Objection

(Patrik Fältström) No Record