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

--=-=-=



Any objections?


--=-=-=
Content-Type: message/rfc822
Content-Disposition: inline

Return-Path: <[email protected]>
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 protected]>
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 protected]>; 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 protected]>; 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 protected]>; 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)
Date: Wed, 14 Dec 2005 20:00:45 +0900
Message-ID: <20051214200045JK%[email protected]>
From: "KAMADA Ken'ichi" <[email protected]>
To: [email protected], [email protected]
Cc: [email protected], [email protected],
	[email protected], [email protected],
	[email protected], [email protected], [email protected]
Subject: Re: [Gen-art] Gen-Art LC Review: draft-ietf-kink-kink-11.txt
In-Reply-To: <[email protected]>
References: <[email protected]>
	<20051214093320JG%[email protected]>
	<[email protected]>
User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7
 =?iso-8859-1?q?=28Sanj=F2=29?= 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-Level: 
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

At Tue, 13 Dec 2005 19:49:41 -0500,
"Joel M. Halpern" <[email protected]> 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 protected]>


--=-=-=--