Subject: [KAMADA Ken'ichi] Re: [Gen-art] Gen-Art LC Review: draft-ietf-kink-kink-11.txt

From: Sam Hartman <[email-masked]>
Date: Wed, 14 Dec 2005 13:29:23 -0500

Any objections?

Subject: Re: [Gen-art] Gen-Art LC Review: draft-ietf-kink-kink-11.txt
From: "KAMADA Ken'ichi" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Wed, 14 Dec 2005 20:00:45 +0900

At Tue, 13 Dec 2005 19:49:41 -0500,
"Joel M. Halpern" <[email-masked]> wrote:
> 
> But the document never actually states that encapsulation rule.
> I could tell from the examples that was what you intended.
> But the words need to actually say it.
> 
> The current text of KINK_ENCRYPT just states that it carries some 
> sub-values.  It does not state what the sub-values are, nor that if used it 
> should carry all content except the KINK_AP_REQ.

I see your point.
I added a paragraph about the content of KINK_ENCRYPT in section 6.
Some notes:
 1) As I also think message construction is suitable for section 6
    (as with Sakane-san), I added the paragraph there.
 2) DELETE and STATUS messages may also contain a KINK_ENCRYPT
    payload.  I'd like to add the description in the generic part of
    section 6 rather than in the subsection of each command/reply.

BTW, when clarifying KINK_ENCRYPT, I noticed that section 6.3
indicates that KINK_ENCRYPT in a CREATE message is optional.
I suspect this is a mistake.
Mike, could you confirm this is not intentional?
If not, I'd like to change that as well.

Section 4.2.7., para. 1:
OLD:

    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.

NEW:

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

Section 6., para. 1:
OLD:

    All commands, responses, and acknowledgments are bound together by
    the XID field of the message header.  The XID is normally a
    monotonically incrementing field, and is used by the initiator to
    differentiate between outstanding requests to a responder.  The XID
    field does not provide replay protection as that functionality is
    provided by the Kerberos mechanisms.  In addition, commands and
    responses MUST use a cryptographic checksum over the entire message
    if the two peers share a key via a ticket exchange.

NEW:

    All commands, responses, and acknowledgments are bound together by
    the XID field of the message header.  The XID is normally a
    monotonically incrementing field, and is used by the initiator to
    differentiate between outstanding requests to a responder.  The XID
    field does not provide replay protection as that functionality is
    provided by the Kerberos mechanisms.  In addition, commands and
    responses MUST use a cryptographic checksum over the entire message

    In all cases in this section, if a message contains a KINK_AP_REQ or
    KINK_AP_REP payload, other KINK payloads MAY be encapsulated in a
    KINK_ENCRYPT payload.  KINK_ISAKMP payloads in a CREATE message and
    in a successful REPLY message MUST be encapsulated.

Section 6.3., para. 2:
OLD:

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

NEW:

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

Section 6.3., para. 4:
OLD:

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

NEW:

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

-- 
KAMADA Ken'ichi <[email-masked]>

---

From: Michael Thomas <[email-masked]>
Date: Wed, 14 Dec 2005 18:06:14 -0800

Sam Hartman wrote:
> 
> Any objections?
> 
> 
> 
> ------------------------------------------------------------------------
> 
> Subject:
> Re: [Gen-art] Gen-Art LC Review: draft-ietf-kink-kink-11.txt
> From:
> CC:
> [email-masked], [email-masked], 
> [email-masked], [email-masked], 
> [email-masked], [email-masked], [email-masked]
> 
> Return-Path:
> <[email-masked]>
> Received:
> from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus 
> v2.1.16-IPv6-Debian-2.1.16-10) with LMTP; Wed, 14 Dec 2005 06:03:02 -0500
> X-Sieve:
> CMU Sieve 2.2
> Return-Path:
> <[email-masked]>
> Received:
> from south-station-annex.mit.edu (SOUTH-STATION-ANNEX.MIT.EDU 
> [18.72.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) 
> (No client certificate requested) by suchdamage.org (Postfix) with ESMTP 
> id 7EDF5138AA for <[email-masked]>; Wed, 14 Dec 2005 06:03:01 
> -0500 (EST)
> Received:
> from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU 
> [18.7.21.83]) by south-station-annex.mit.edu (8.12.4/8.9.2) with ESMTP 
> id jBEB2uWI005653 for <[email-masked]>; Wed, 14 Dec 2005 
> 06:02:58 -0500 (EST)
> Received:
> from nasten.nanohz.org (220x218x5x242.ap220.ftth.ucom.ne.jp 
> [220.218.5.242]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with 
> ESMTP id jBEB0hqA021256 for <[email-masked]>; Wed, 14 Dec 2005 
> 06:00:43 -0500 (EST)
> Received:
> from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org 
> (Postfix) with ESMTP id 3777D64; Wed, 14 Dec 2005 20:00:38 +0900 (JST)
> Received:
> from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by 
> nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 0MGcs7; Wed, 14 Dec 
> 2005 20:00:41 +0900 (JST)
> Message-ID:
> <[email-masked]>
> In-Reply-To:
> <[email-masked]>
> References:
> <[email-masked]> <[email-masked]> 
> <[email-masked]>
> User-Agent:
> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjò) 
> APEL/10.6 Emacs/22.0.50 (i386-unknown-netbsdelf3.99.9) MULE/5.0 (SAKAKI)
> X-Scanned-By:
> MIMEDefang 2.42
> X-Spam-Checker-Version:
> SpamAssassin 3.0.2 (2004-11-16) on solipsist-nation.suchdamage.org
> X-Spam-Status:
> No, score=-1.4 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO 
> autolearn=ham version=3.0.2
> MIME-Version:
> 1.0
> 
> 

It was intentional that KINK_ENCRYPT was optional -- for everything.
I don't really feel very strongly about it at this point other than
general nervousness about making big changes in the document at
this point with a good possibility that the document will be
inconsistent.

		Mike

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Thu, 15 Dec 2005 15:20:04 +0900

At Wed, 14 Dec 2005 18:06:14 -0800,
> this point with a good possibility that the document will be

OK, I withdraw the latter part of the changes.
New proposal is here.

Section 4.2.7., para. 1:
OLD:

NEW:

Section 6., para. 1:
OLD:

NEW:

    KINK_ENCRYPT payload.