Re: Last Call: Kerberized Internet Negotiation of Keys (KINK) toProposed Standard

[OKABE Nobuo <nov@tahi.org>]

Dear IESG and authors,

I'm sorry that I could not keep the deadline.
But we had a chance to examine the KINK draft recently.
We will be happy if our comments help you.

From: The IESG <iesg-secretary@ietf.org>
Subject: Last Call: Kerberized Internet Negotiation of Keys (KINK) to Proposed Standard
Date: Mon, 11 Nov 2002 13:23:00 -0500

> The IESG has received a request from the Kerberized Internet Negotiation 
> of Keys Working Group to consider Kerberized Internet Negotiation of 
> Keys (KINK) <draft-ietf-kink-kink-04.txt> as a Proposed Standard.  
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the 
> iesg@ietf.org or ietf@ietf.org mailing lists by 2002-12-11.
> 
> Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-kink-kink-04.txt

Here are our comments.

=====================================================================
7.3.  CREATE

   This   message   initiates   an   establishment   of   new   Security
   Association(s). The CREATE message must contain an AP-REQ payload and
   any DOI specific payloads.

   CREATE KINK Header
     KINK_AP_REQ
     [KINK_ENCRYPT]
       KINK_ISAKMP payload
            SA Payload[s]
                 Proposal Payloads
                         Transform Payloads
            Nonce Payload (Ni)
            [KE]
            [IDci, IDcr]
            [Notification Payloads]

   Replies are of the following forms:

   REPLY KINK Header
     KINK_AP_REP
     [KINK_ENCRYPT]
       KINK_ISAKMP
            SA Payload[s]
                   Proposal Payload
                           Transform Payload
            [ Nonce Payload (Nr)]
            [IDci, IDcr]
            [Notification Payloads]
=====================================================================

Comment 1)

    If a respondent's CPU is too poor for DH (ex. 8-bit CPU),
    it has to reject a proposal that includes KE payload.
    What message should the responder back to the initiator?
    Is NO-PROPOSAL-CHOSEN right one?
    Anyway, more specific description seems to be needed.

Comment 2)

    There is no KE payload in a reply message.
    Is it typo?

Comment 3)

    # This comment is related the above (Comment 2).

    Does a two-way handshake keep going if KINK peers exchanges
    KE payloads (in request and in reply)?
    The optimistic approach will be broken if DH is happen
    after the initiator receives KE payload in a reply message.
    But I'm not sure if ACK is needed or not.

=====================================================================
8.  Key Derivation

   KINK uses the same key derivation mechanisms that [IKE] uses in sec-
   tion 5.5, which is:

   KEYMAT = prf(SKEYID_d, [g(qm)^xy |] protocol | SPI | Ni_b [| Nr_b])

   The following differences apply:

   o  SKEYID_d is the session key in the Kerberos service ticket from
      the AP-REQ.

   o  Nr_b is optional

      By optional, it is meant that the equivalent of a zero length
      nonce was supplied.

      Note that g(qm)^xy refers to the keying material generated when KE
      payloads are supplied using Diffie Hellman key agreement. This is
      explained in section 5.5 of [IKE].
=====================================================================

Comment 4)

   The draft does not define "prf".
   In IKE's case, a phase 1 negotiates a hash algorithm
   that is used for prf. But KINK does not use IKE phase 1.
   # I guess that the hash algorithm specified in the Kerberos ticket
   # is used.

Again, I apologize if my mail disturbs you.

Best Regards,

---- nobuo