Re: [HOKEY] AD review of draft-ietf-hokey-erp-aak

Zhen Cao <zehn.cao@gmail.com> Fri, 13 January 2012 02:50 UTC

Return-Path: <zehn.cao@gmail.com>
X-Original-To: hokey@ietfa.amsl.com
Delivered-To: hokey@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DD221F85EE for <hokey@ietfa.amsl.com>; Thu, 12 Jan 2012 18:50:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.039
X-Spam-Level:
X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1]
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 zfTiEC34KvVE for <hokey@ietfa.amsl.com>; Thu, 12 Jan 2012 18:50:40 -0800 (PST)
Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A577721F85ED for <hokey@ietf.org>; Thu, 12 Jan 2012 18:50:40 -0800 (PST)
Received: by obcwo10 with SMTP id wo10so1918967obc.31 for <hokey@ietf.org>; Thu, 12 Jan 2012 18:50:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=orCOUlVz+sHRdz5RseAenj3HfdaomcXLeYYmiQKdWfU=; b=TIn8N/bOx8LUp+Wit8a4Oq2VCHNmmj6JJ4ykBt2CkDVc5QLdoXi2Gv4EUl9jtZ7HVU BH0fg6QuPK8hKNu55pKBPpd1YCK3lS+tWZoUP7iE8c5lKDAumQH6CnnFaLDBVeBphU4a u3VsBa8m4/zCRpJ/Qc7uaOzCtBoDSxRdRlJtU=
MIME-Version: 1.0
Received: by 10.50.170.1 with SMTP id ai1mr3721756igc.13.1326423040227; Thu, 12 Jan 2012 18:50:40 -0800 (PST)
Received: by 10.42.174.67 with HTTP; Thu, 12 Jan 2012 18:50:40 -0800 (PST)
In-Reply-To: <4F0EB323.2090309@cs.tcd.ie>
References: <4ECA9AD5.3050409@cs.tcd.ie> <B5D72BE948614EB6BA4D5DCDD907074C@china.huawei.com> <4ECE2EC9.6040408@cs.tcd.ie> <03FB617435B7413D8F0381C5D4689806@china.huawei.com> <4ECE4300.8070901@cs.tcd.ie> <CAProHAT4dSpfeAqbDcH7YNiZC6N0bQ9Wgnq3EqzpvXkHoTAx6g@mail.gmail.com> <4F0EB323.2090309@cs.tcd.ie>
Date: Fri, 13 Jan 2012 10:50:40 +0800
Message-ID: <CAProHATL1WerjbK=7zJOmwcWi41J+S8Rss6wUKzKT6QcfQ-kZA@mail.gmail.com>
From: Zhen Cao <zehn.cao@gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Glen Zorn <glenzorn@gmail.com>, "Cao, Zhen" <caozhen@chinamobile.com>, hokey@ietf.org
Subject: Re: [HOKEY] AD review of draft-ietf-hokey-erp-aak
X-BeenThere: hokey@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: HOKEY WG Mailing List <hokey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hokey>, <mailto:hokey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hokey>
List-Post: <mailto:hokey@ietf.org>
List-Help: <mailto:hokey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hokey>, <mailto:hokey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Jan 2012 02:50:41 -0000

Thanks a lot.  I will work out the revision with my co-authors soon.

On Thu, Jan 12, 2012 at 6:17 PM, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:
>
> Hiya,
>
> A few notes below but mostly those changes look like they
> should be fine.
>
> Any idea when the new I-D will pop out? Be good to get this
> moving along...
>
>

>
> I think if you added more text to explain the hierarchy that'd
> be good for the reader. But if you say that's known to folks who
> are familiar with ERP I can live with that. Good to add the
> KDFs all right.
>
okay.


>> #17, p8 - Is the sequence number TLV called "Sequence"? If not,
>> then are you allowed spaces in TLV names?
>>
>> [CZ]: In this draft, the sequence number is defined as TV format
>> rather than TLV format.
>> In the sequence number TV format, 8 bit type for sequence number will
>> be followed by 16 bit
>> Sequence number value.
>
>
> I was really asking about whether or not TV or TLV names can be
> anything of it there's a rule or convention e.g. not include
> spaces in those names. (Now that I look I see you also have some
> TV names with a "/" character in them). I guess that's a bit
> of a nit though.
>
> But now that you mention it, where does it say that the sequence
> number TV value is 16 bits long? It does say that for the SEQ
> field but maybe needs repeating.

That's the same with ERP, but we will also mention it in our document.


>> [CZ]: In the request (i.e.,EAP-Initiate/Re-auth) message to the
>> server, only CAP-Identifier needs to be present
>> In the response (i.e.,EAP-Finish/Re-auth) message from the server, all
>> the sub TLV including CAP-Identifier and pMSK-lifetime and Cryptosuit
>> should be present in the message.
>
>
> I think that needs to be specified here. So adding that would
> be good (unless its there already and I missed it;-)

Thanks.

>> #26, p10 - From when is the lifetime of the pMSK calculated? (Same
>> for the pRK-lifetime field.) Are these signed or unsigned 32-bit
>> values?
>>
>> [CZ]: Upon receiving EAP-Initiate message from the peer, the server
>> begin to calculate pRK,pMSK.
>> Upon receiving EAP-Finish message, the peer begin to calculate PMSK,pRK.
>
>
> Ok. I think you need to say that. And also specify if the 32 bits
> are unsigned or signed. (Signed probably makes no sense really but
> good to say that.) Note that time_t is signed so there's an easy
> bug for coders to trip over here.
>
> I think there's no harm here in large values, right? Since 2^32 seconds
> is 136 years there could be a DoS if something were just stored that
> long but I believe that's not a problem. Correct me if I'm wrong.

Correct. unsigned 32 bits. Thank you.

>> #31, p10 - The list of cryptosuites desription says "The server
>> SHOULD include this if the...was not acceptable and is being
>> rejected." That's pretty ambiguous. What's the exception to the
>> SHOULD? Does "is being rejected" mean that this MUST NOT be present
>> when things worked ok?
>>
>> [CZ]: No. You have some misunderstanding to the cryptosuite descrption.
>> We define Cryptosuite field in both EAP-initiate message and EAP-Finish
>> message,
>> We also allow carry Crytosuite List TLV( Type is 5) in both
>> EAP-Initiate message and EAP-Finish message.
>> If Cryptosuite included in the Cryptosuite field of EAP-Initiate
>> message is rejected by the server, the server can indicate to the peer
>> the cryptosuit list the server supports using cryptosuite list TLV.
>> Does this clarify?
>
>
> Yep. Good to say that in the spec (unless its there and I missed
> it as usual:-)

okay.

>
>> #33, p11 - Section 7 says a new message "should" be defined - who's
>> gonna do that where? Seems odd that its not here.
>>
>> [CZ]: Could be removed if you think odd.
>
>
> I think it is odd. Is this something that's needed though? If
> so, who's doing the work or in what document is the required
> message defined? What are the consequences of that not being
> defined?

okay, will remove this.