Kerberized Internet Negotiation of Keys (KINK)
RFC 4430

[Note]: 'A draft 11 has been submitted to address last call comments.
Back to IESG to clear discusses and pick up positive ballots.  It''s
been a long time since this was here (early 2003) and the document has
changed significantly.  A full re-review is probably in order.' added by Amy Vezza

IANA Comments:
Upon approval of this document the IANA will assign a well known port number in the following registry: http://www.iana.org/assignments/port-numbers.

The IANA will also create a registry for KINK Parameters which will include KINK Message Types, KINK Next Payload Types and KINK Error Codes.

An expert will need to be designated.

Section 5.1, 5.3 and 5.5 appear to have listings of numbers.  Does the IANA need to do anything with these?

[Note]: 'A draft 11 has been submitted to address last call comments.
Back to IESG to clear discusses and pick up positive ballots.  It''s
been a long time since this was here (early 2003) and the document has
changed significantly.  A full re-review is probably in order.' added by Michelle Cotton

[Ballot comment]
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

[Ballot comment]
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.

[Note]: 'A draft 11 has been submitted to address last call comments.
Back to IESG to clear discusses and pick up positive ballots.  It''s
been a long time since this was here (early 2003) and the document has
changed significantly.  A full re-review is probably in order.' added by Sam Hartman

[Note]: 'Back to IESG to clear discusses and pick up positive ballots.  It''s
been a long time since this was here (early 2003) and the document has
changed significantly.  A full re-review is probably in order.' added by Sam Hartman

[Ballot discuss]
Discuss comment transferred from old ballot:

There is no wording about how to compare for example realms. Is this a
resolved issue with the kerberos protocol? I.e. normally the realm in
kerberos is case _sensitive_ but when using DNS together with realms
(SRV-records) one say the realm name is the same as the domain name,
which is case _insensitive_.

Does this not create a need for an explicit note in this document about
how to compare the attributes which are compared?

I can not find any, but might have the wrong regexp in my grep.

[Ballot discuss]
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

[Ballot comment]
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?

[Note]: 'Returned to working group with extensive AD re-review.  Many comments
need to be addressed although few if any fundamental changes.  In
significant part the comments are because both Kerberos and IPsec
evolved while this spec was languishing before the IESG.
Comments have been sent to the wg mailing list.' added by Sam Hartman

[Ballot discuss]
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?

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

p 3:  the definition of "principal" uses the x.509 equivalence twice.

Section 4.4.2: is this compatible with IKE's dead peer detection
philosophy?  I think not -- it relies on explicit IKE probes.  KINK
says that the IPsec layer should do stuff.  (The fact that I agree with
you is irrelevant...)

Section 5: how is the key incorporated into the checksum?  I don't
recall if "Kerberos etype" is a sufficient definition, but the text says to
use SHA1 if there is no etype hash function.  How?

5.1.1: Do checksum lengths, etc., count the padding?

5.1.5: What Kerberos instance name should be used?

5.1.7: If the version numbers do not correspond to ISAKMP version
numbers, and if KINK has its own, what are these versions of?  Just
quick mode?  I'm not at all convinced that there could be a new quick
mode version without a new ISAKMP version.

5.1.8: Is this clear enough, given that it isn't quite Kerberos
encryption?  (Also -- and again without going back to the Kerberos spec
-- as I recall it used some funky home-grown integrity scheme,
rather than HMAC or even a keyed hash.  True?  Is that carried forward
into KINK?)

6.5: How are the nonce payloads used in key generation?

How, precisely, are keys generated?  I thought that Kerberos only
generated one session key; IPsec normally uses one for each direction.
(Or am I wrong about Kerberos?)

What is the algorithm for dealing with version numbers, to prevent
rollback attacks?

There needs to be a section that discusses, in at least broad terms,
how to cope with son-of-IKE.