Kerberized Internet Negotiation of Keys (KINK)
RFC 4430
Discuss
Yes
(Jeffrey Schiller)
(Sam Hartman)
(Steven Bellovin)
No Objection
(Alex Zinin)
(Bert Wijnen)
(Bill Fenner)
(Harald Alvestrand)
(Jon Peterson)
(Margaret Cullen)
(Mark Townsley)
(Ned Freed)
(Randy Bush)
(Scott Hollenbeck)
(Ted Hardie)
(Thomas Narten)
No Record
(Patrik Fältström)
Note: This ballot was opened for revision 11 and is now closed.
Scott Bradner Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2005-08-18)
Unknown
notes:
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
Jeffrey Schiller Former IESG member
Yes
Yes
()
Unknown
Sam Hartman Former IESG member
Yes
Yes
()
Unknown
Steven Bellovin Former IESG member
Yes
Yes
()
Unknown
Alex Zinin Former IESG member
No Objection
No Objection
()
Unknown
Allison Mankin Former IESG member
No Objection
No Objection
(2005-08-17)
Unknown
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?
Bert Wijnen Former IESG member
No Objection
No Objection
()
Unknown
Bill Fenner Former IESG member
No Objection
No Objection
()
Unknown
Brian Carpenter Former IESG member
No Objection
No Objection
(2005-12-13)
Unknown
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 applied. 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 http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-kink-kink-10-halpern.txt
Harald Alvestrand Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Margaret Cullen Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Ned Freed Former IESG member
No Objection
No Objection
()
Unknown
Randy Bush Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2005-12-12)
Unknown
Section 1: s/peer to peer/peer-to-peer/ Section 10: s/perfect forward secrecy/perfect forward secrecy (PFS)/
Scott Hollenbeck Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Ted Hardie Former IESG member
No Objection
No Objection
()
Unknown
Thomas Narten Former IESG member
No Objection
No Objection
()
Unknown
Patrik Fältström Former IESG member
No Record
No Record
()
Unknown