[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Gen-Art LC Review: draft-ietf-kink-kink-11.txt
- To: joel@xxxxxxxxxxxxxxxx
- Subject: Re: Gen-Art LC Review: draft-ietf-kink-kink-11.txt
- From: Shoichi Sakane <sakane@xxxxxxxx>
- Date: Wed, 14 Dec 2005 11:39:07 +0900
- Cc: gen-art@xxxxxxxx, hartmans-ietf@xxxxxxx, ietf-kink@xxxxxxxx, derek@xxxxxxxxx, jtrostle@xxxxxxxxxxxxx, Shouichi.Sakane@xxxxxxxxxxxxxxx, Ken-ichi.Kamada@xxxxxxxxxxxxxxx, mat@xxxxxxxxx, vilhuber@xxxxxxxxx, sakane@xxxxxxxx
- In-reply-to: Your message of "Sat, 10 Dec 2005 16:42:22 -0500" <6.2.1.2.0.20051210152503.03137720@mail.stevecrocker.com>
- List-archive: <http://www.vpnc.org/ietf-kink/mail-archive/>
- List-id: <ietf-kink.vpnc.org>
- List-unsubscribe: <mailto:ietf-kink-request@vpnc.org?body=unsubscribe>
- References: <6.2.1.2.0.20051210152503.03137720@mail.stevecrocker.com>
- Sender: owner-ietf-kink@xxxxxxxxxxxxx
Hi,
Section 4 explains the format of each KINK payload. Section 6 explains
the structure of each KINK message. I agree that tehre is no description
about the contents of "Payload" of KINK_ENCRYPT.
Would it be enough if there was the following text into section 4.2.7 ?
The construction encapsulated in the payload of KINK_ENCRYPT
describes at section 6.
> I was selected as General Area Review Team reviewer for this specification
> (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> This document appears to be ready for publication as a proposed standard.
> I do have one minor comment below. This may be a result of the fact that I
> am not a security expert and may well have misread the document.
>
> Minor:
> 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.
>
> Yours,
> Joel M. Halpern
>
> [Multiple copies of comment sent according to gen-art procedures.]
>
> ----
> SEC: Kerberized Internet Negotiation of Keys (KINK)
> draft-ietf-kink-kink-11.txt
>
> Responsible AD: Sam Hartman
> Reviewer: Joel Halpern
>
>