Skip to main content

Kerberized Internet Negotiation of Keys (KINK)
draft-ietf-kink-kink-11

Revision differences

Document history

Date Rev. By Action
2012-08-22
11 (System) post-migration administrative database adjustment to the No Objection position for Scott Hollenbeck
2012-08-22
11 (System) post-migration administrative database adjustment to the No Objection position for Randy Bush
2012-08-22
11 (System) post-migration administrative database adjustment to the No Record position for Patrik Faltstrom
2005-12-20
11 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2005-12-19
11 Amy Vezza IESG state changed to Approved-announcement sent
2005-12-19
11 Amy Vezza IESG has approved the document
2005-12-19
11 Amy Vezza Closed "Approve" ballot
2005-12-16
11 (System) Removed from agenda for telechat - 2005-12-15
2005-12-15
11 Amy Vezza State Changes to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation by Amy Vezza
2005-12-15
11 Amy Vezza
[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 …
[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
2005-12-15
11 (System) [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin
2005-12-15
11 (System) [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner
2005-12-15
11 (System) [Ballot Position Update] New position, No Objection, has been recorded for Ned Freed
2005-12-15
11 (System) [Ballot Position Update] New position, Yes, has been recorded for Steven Bellovin
2005-12-15
11 (System) [Ballot Position Update] New position, Yes, has been recorded for Jeffrey Schiller
2005-12-15
11 (System) [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen
2005-12-15
11 (System) [Ballot Position Update] New position, No Objection, has been recorded for Thomas Narten
2005-12-15
11 (System) [Ballot Position Update] Position for Allison Mankin has been changed to No Objection from No Record
2005-12-15
11 (System) [Ballot Position Update] Position for Randy Bush has been changed to No Objection from No Record
2005-12-15
11 (System) [Ballot Position Update] Position for Scott Bradner has been changed to Discuss from No Record
2005-12-15
11 (System) [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand
2005-12-15
11 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley
2005-12-15
11 Michelle Cotton
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 …
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?
2005-12-15
11 Michelle Cotton
[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 …
[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
2005-12-14
11 Sam Hartman State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Sam Hartman
2005-12-13
11 Scott Hollenbeck [Ballot Position Update] Position for Scott Hollenbeck has been changed to No Objection from Discuss by Scott Hollenbeck
2005-12-13
11 Brian Carpenter
[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 …
[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
2005-12-13
11 Brian Carpenter
[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 …
[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.
2005-12-13
11 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter
2005-12-12
11 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2005-12-12
11 Russ Housley [Ballot comment]
Section 1: s/peer to peer/peer-to-peer/

  Section 10: s/perfect forward secrecy/perfect forward secrecy (PFS)/
2005-12-12
11 Scott Hollenbeck [Ballot discuss]
A normative reference to RFC 2119 is needed.
2005-12-12
11 Scott Hollenbeck [Ballot Position Update] New position, Discuss, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2005-12-09
11 (System) New version available: draft-ietf-kink-kink-11.txt
2005-12-08
11 Sam Hartman [Ballot Position Update] New position, Yes, has been recorded for Sam Hartman
2005-12-08
11 Sam Hartman Ballot has been issued by Sam Hartman
2005-12-08
11 Sam Hartman
[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 …
[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
2005-12-08
11 Sam Hartman Status date has been changed to 2005-12-08 from 2005-01-01
2005-12-08
11 Sam Hartman Placed on agenda for telechat - 2005-12-15 by Sam Hartman
2005-12-08
11 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 …
[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
2005-11-28
11 Amy Vezza Last call sent
2005-11-28
11 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2005-11-28
11 Amy Vezza Last Call was requested by Amy Vezza
2005-11-28
11 Amy Vezza State Changes to Last Call Requested from AD Evaluation by Amy Vezza
2005-11-28
11 (System) Ballot writeup text was added
2005-11-28
11 (System) Last call text was added
2005-11-28
11 (System) Ballot approval text was added
2005-11-21
11 Sam Hartman Status date has been changed to 2005-011-21 from 2005-01-30
by Sam Hartman
2005-11-21
11 Sam Hartman [Note]: 'Back from working group after alignment with kerberos and ipsec.n' added by Sam Hartman
2005-11-21
11 Sam Hartman State Changes to AD Evaluation from Publication Requested by Sam Hartman
2005-11-09
11 Dinara Suleymanova State Changes to Publication Requested from AD is watching by Dinara Suleymanova
2005-10-11
10 (System) New version available: draft-ietf-kink-kink-10.txt
2005-08-18
11 Patrik Fältström
[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 …
[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.
2005-08-18
11 Scott Bradner
[Ballot discuss]
notes:
                at 36 pages this doc should have a table of contents
      …
[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
2005-08-17
11 Allison Mankin
[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 …
[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?
2005-08-17
11 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Amy Vezza
2005-08-17
11 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Amy Vezza
2005-08-17
11 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Amy Vezza
2005-08-17
11 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Amy Vezza
2005-08-09
11 Sam Hartman State Changes to AD is watching from Dead by Sam Hartman
2005-07-20
09 (System) New version available: draft-ietf-kink-kink-09.txt
2005-07-11
08 (System) New version available: draft-ietf-kink-kink-08.txt
2005-05-27
07 (System) New version available: draft-ietf-kink-kink-07.txt
2005-05-26
11 (System) State Changes to Dead from AD is watching by IESG Secretary
2005-01-30
11 Sam Hartman State Changes to AD is watching from IESG Evaluation::AD Followup by Sam Hartman
2005-01-30
11 Sam Hartman
[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 …
[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
2005-01-30
11 Sam Hartman Status date has been changed to 2005-01-30 from 2002-12-11
2004-11-12
11 Sam Hartman Shepherding AD has been changed to Sam Hartman from Steve Bellovin
2004-11-12
11 Steven Bellovin Needs another read-through by IANA
2004-07-15
11 (System) Sub state has been changed to AD Follow up from New Id Needed
2004-07-15
06 (System) New version available: draft-ietf-kink-kink-06.txt
2003-08-11
11 Michael Lee Removed from agenda for telechat - 2003-08-07 by Michael Lee
2003-08-07
11 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2003-08-04
11 Randy Bush
[Ballot discuss]
if there is to be kerberos sales literature

      The central key management provided by Kerberos is efficient because
    …
[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
2003-08-04
11 Randy Bush Created "Approve" ballot
2003-07-15
11 Steven Bellovin revious discusses are all cleared, but it's been a while, and there are new ADs.
2003-07-15
11 Steven Bellovin State Changes to IESG Evaluation from AD Evaluation  :: AD Followup by Bellovin, Steve
2003-04-30
11 Steven Bellovin State Changes to AD Evaluation  :: AD Followup from AD Evaluation  :: External Party by Bellovin, Steve
2003-02-09
11 Steven Bellovin Authors queried -- one point apparently not addressed.
2003-02-09
11 Steven Bellovin State Changes to AD Evaluation  :: External Party from AD Evaluation by Bellovin, Steve
2003-02-03
11 Steven Bellovin State Changes to AD Evaluation from AD Evaluation  :: External Party by Bellovin, Steve
2003-01-31
05 (System) New version available: draft-ietf-kink-kink-05.txt
2002-12-12
11 Steven Bellovin Notified authors of IESG comments.  Not clear if they
can be resolved with an RFC editor's note, or if a new version is needed.
2002-12-12
11 Steven Bellovin State Changes to AD Evaluation  :: External Party from IESG Evaluation by Bellovin, Steve
2002-12-02
11 Steven Bellovin State Changes to IESG Evaluation from Waiting for Writeup by Bellovin, Steve
2002-11-27
11 Steven Bellovin State Changes to Waiting for Writeup from In Last Call by Bellovin, Steve
2002-11-11
11 Jacqueline Hargest Due date has been changed to 2002-12-11 from 
by Hargest, Jacqueline
2002-11-11
11 Jacqueline Hargest State Changes to In Last Call from Last Call Requested by Hargest, Jacqueline
2002-11-11
11 Steven Bellovin State Changes to Last Call Requested from AD is watching by Bellovin, Steve
2002-11-06
04 (System) New version available: draft-ietf-kink-kink-04.txt
2002-11-04
11 Steven Bellovin Waiting for new version to appear, at which point Last Call will be scheduled.
2002-11-04
11 Steven Bellovin by Bellovin, Steve
2002-11-04
11 Steven Bellovin State Changes to AD is watching  :: Revised ID Needed from AD is watching  :: AD Followup by Bellovin, Steve
2002-10-31
11 Steven Bellovin Evaluating responses from authors.
2002-10-31
11 Steven Bellovin by Bellovin, Steve
2002-10-31
11 Steven Bellovin State Changes to AD is watching  :: AD Followup from AD is watching  :: Revised ID Needed by Bellovin, Steve
2002-10-02
11 Steven Bellovin State Changes to WG/Author  -- New ID Needed from WG/Author  -- Point Raised - writeup needed by bellovin
2002-09-24
11 Steven Bellovin responsible has been changed to Working Group from Area Directors
2002-09-23
11 Steven Bellovin
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 …
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.
2002-09-23
11 Steven Bellovin A new comment added
by bellovin
2002-09-23
11 Steven Bellovin State Changes to In WG  -- Point Raised from AD Evaluation by bellovin
2002-08-22
11 Steven Bellovin Draft Added by bellovin
2002-08-16
03 (System) New version available: draft-ietf-kink-kink-03.txt
2001-11-27
02 (System) New version available: draft-ietf-kink-kink-02.txt
2001-07-23
01 (System) New version available: draft-ietf-kink-kink-01.txt
2000-10-05
00 (System) New version available: draft-ietf-kink-kink-00.txt