Re: [Pana] Fwd: New Version Notification for draft-yegin-pana-encr-avp-01.txt

Robert Cragie <robert.cragie@gridmerge.com> Tue, 10 April 2012 10:28 UTC

Return-Path: <robert.cragie@gridmerge.com>
X-Original-To: pana@ietfa.amsl.com
Delivered-To: pana@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0836421F869E for <pana@ietfa.amsl.com>; Tue, 10 Apr 2012 03:28:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TTKYFGv7aee for <pana@ietfa.amsl.com>; Tue, 10 Apr 2012 03:28:48 -0700 (PDT)
Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE1D21F85A8 for <pana@ietf.org>; Tue, 10 Apr 2012 03:28:47 -0700 (PDT)
Received: from client-86-31-84-145.midd.adsl.virginmedia.com ([86.31.84.145] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1SHYJZ-0007jK-1w for pana@ietf.org; Tue, 10 Apr 2012 11:28:45 +0100
Message-ID: <4F840BBB.9000302@gridmerge.com>
Date: Tue, 10 Apr 2012 11:30:19 +0100
From: Robert Cragie <robert.cragie@gridmerge.com>
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: pana@ietf.org
References: <20120104095307.27035.33867.idtracker@ietfa.amsl.com> <4F631E51.6030302@gridmerge.com> <4F7005FF.4030609@isl.rdc.toshiba.co.jp>
In-Reply-To: <4F7005FF.4030609@isl.rdc.toshiba.co.jp>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms040400070707080406050006"
X-Authenticated-As: robert.cragie@gridmerge.com
Subject: Re: [Pana] Fwd: New Version Notification for draft-yegin-pana-encr-avp-01.txt
X-BeenThere: pana@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: Protocol for carrying Authentication for Network Access <pana.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pana>, <mailto:pana-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pana>
List-Post: <mailto:pana@ietf.org>
List-Help: <mailto:pana-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2012 10:28:49 -0000

Tanaka-san,

Thank you for your comments. I have responded inline, bracketed by 
<RCC></RCC>.

Robert

On 26/03/2012 7:00 AM, Yasuyuki Tanaka wrote:
> Hi,
>
> I've read the draft and I have four comments. Please see them below.
>
> Best,
> Yasuyuki Tanaka
>
> ---------------------------------------------------------------------
>
> (1) Section 3
> I found a typo in the last sentence.
>
> >   The length of PANA_ENCR_KEY depends on the integrity algorithm in
> >   use.
>
> should be
>
>     The length of PANA_ENCR_KEY depends on the *encryption* algorithm in
>     use.
<RCC>Agreed, good catch.</RCC>
>
> ---------------------------------------------------------------------
>
> (2) Section 4
> I've not found text about key size of AES to be used for
> AES_CTR. Probably 128-bit is assumed.
>
> It would be better to clarify the key size to be used for the
> algorithm and to use "AES128_CTR" or something instead of "AES_CTR".
<RCC>Agreed.</RCC>
>
> ---------------------------------------------------------------------
>
> (3) Section 4
> The definition of "q" is different between the draft and NIST
> SP800-38C. In this draft, "q" is defined as "octet length of message
> length field." But in NIST SP800-38C, "q" is defined as "The octet
> length of the binary representation of the octet length of the
> payload."
>
> In addition, I don't realize what 'length of message length field'
> means... Why is "q" 3? The length of "Message Length" field of PANA
> Message Header is 2 octets...
>
> Anyway, I think the following part might cause some confusion.
>
> >      AES-CTR (Counter) encryption algorithm as specified in
> >      [NIST_SP800_38A].  The formatting function and counter generation
> >      function as specified in Appendix A of [NIST_SP800_38C] are used,
> >      with the following parameters:
> >
> >
> >            n, octet length of nonce, is 12.
> >            q, octet length of message length field, is 3.
>
> IMHO, it's better to say just "q is 3" as the definition of "q".
<RCC>Agreed. It was chosen at 3 to be consistent with the use of CCM in 
the proposed TLS cipher suites.</RCC>
>
> ---------------------------------------------------------------------
>
> (4) Section 4
> It would be very helpful to provide an example of the first counter.
>
> When Key-Id is 0x55667788, Session ID is 0xaabbccdd, and Sequence
> Number is 0x11223344, the correct first counter is
> 0x0255667788aabbccdd11223344000001. is it correct?
<RCC>That is correct. I will include the example as given.</RCC>