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

Qin Wu <bill.wu@huawei.com> Thu, 24 November 2011 06:09 UTC

Return-Path: <bill.wu@huawei.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 F323721F8B40 for <hokey@ietfa.amsl.com>; Wed, 23 Nov 2011 22:09:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.794
X-Spam-Level:
X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[AWL=1.805, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 hwTOdIUWg2XL for <hokey@ietfa.amsl.com>; Wed, 23 Nov 2011 22:09:15 -0800 (PST)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 84A9D21F8B43 for <hokey@ietf.org>; Wed, 23 Nov 2011 22:09:15 -0800 (PST)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LV500ENUIF5MZ@szxga05-in.huawei.com> for hokey@ietf.org; Thu, 24 Nov 2011 14:09:05 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LV500HD5IEKB4@szxga05-in.huawei.com> for hokey@ietf.org; Thu, 24 Nov 2011 14:09:05 +0800 (CST)
Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFF57734; Thu, 24 Nov 2011 14:09:04 +0800
Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 24 Nov 2011 14:08:58 +0800
Received: from w53375q (10.138.41.130) by szxeml406-hub.china.huawei.com (10.82.67.93) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 24 Nov 2011 14:08:53 +0800
Date: Thu, 24 Nov 2011 14:08:53 +0800
From: Qin Wu <bill.wu@huawei.com>
X-Originating-IP: [10.138.41.130]
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, hokey@ietf.org
Message-id: <B5D72BE948614EB6BA4D5DCDD907074C@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
X-CFilter-Loop: Reflected
References: <4ECA9AD5.3050409@cs.tcd.ie>
Cc: Glen Zorn <glenzorn@gmail.com>, "Cao,Zhen" <caozhen@chinamobile.com>
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: Thu, 24 Nov 2011 06:09:17 -0000

Hi, Stephen:
Thank for your valuable review. 
Here is my answer to the main issues I think and I skip most of editorial issues or nits issues.  
My coauthors will address the remaining issues.
----------------------------------------
#7, p5 - "The rIK is used to protect this message." Is that right?
How is rIK used to protect the message when the message contain
rIK?  I also wondered what "protect" means exactly - are the flags
etc. all protected and how? 

[Qin] I think rIK should be corrected as pIK. pIK is used to protect the ERP message
exchanged between the peer and the EA server. MSK used for normal EAP exchange should be further derived into
other child keys. Alternatively, the pMSK can be derived into child keys. These child keys protect the ERP 
message exchanged between the peer and SAP.

#8, p5 - If I'm an authenticated user and I send the message at
step 2 to the SAP, then can I get the SAP to forward the message to
anything on the Internet? If not, where does it say how that's
controlled? I guess the SAP knows based on its config and/or the
authentication state of the peer but if so you should probably say
that?

[Qin]: SAP plays the role of authenticator should encapsulate the ERP message
into AAA message and route the AAA message based on Realm part of KeyName-NAI.

#15, p8 - You can only have one keyName-NAI in the message and that
MAY have either the home domain name or the domain name to which
the peer is currently attached for ite realm part.  How does anyone
know which to include when? Seems underspecified or missing a
reference?

[Qin]: This was discussed on the list many times. Based on the discussion,
we take the following way:
The peer should know where to send the message? If the peer
communicate with the home server, the peer should carry home domain name
in the keyName-NAI. If the peer communicate with the local server, the peer
should carry local domain name in the keyName-NAI.
The authenticator or local ER server in the path can know if the KeyName-NAI carry 
local domain name by comparing the domain name carried in KeyName-NAI with local 
domain name it has already known.

#16, p8 - How are CAP-Identifier and "Sequence number" TLVs
"associated"?

[Qin]: Suppose multiple CAP-identifiers are carried in the ERP message,
the same number of Sequence number TLVs should be carried with associated CAP-identifier.
We can rely on the order to associate each other.

#18, p8 - Exactly how is the sequence number used in the
calculation of the pMSK for each CAP? Can these be re-used? (Across
reboots?) Do they need to be random? That all needs stating I
think.

[Qin]: This was discussed on the list before. The results is:
If we carry three CAP-Identifiers, we should also send three Sequence number TLVs 
with associated CAP-Identifiers. The Sequence number for each CAP MUST not be reused.

#20, p8 - authentication tag - where is the input to the HMAC
function specified? (Its not here anyway.) I think someone needs to
say how this is calculated. That means both the plaintext (message)
input (e.g. are any header bits in/excluded?) and the key input
(which key?). It could be that this just needs a reference if its
done the same as some other RFC. An example would be great to give.

[Qin]: We should base on HMAC mechanims specified in RFC2104,
Use the integrity algorithm indicated in the Cryptosuite field to 
calculate authentication tag value. rIK will be used for calculation.
The message used to calculate authentication tag should exclude authentication
tag field and but not exclude header bits.

#22, p8 - You need references for the HMAC functions.

[Qin] It should be RFC2104.

#23, p8 - Should/are the choices for cryptosuites in some IANA
registry?  If not, why not? If so, where?

[Qin] RFC5296 has already created registries for'Re-authentication
   Cryptosuites'. These crytosuites can be reused for ERP-AAK.

#36, p11 - Is it ok for "different sequence numbers" to mean "just
increment" or not?  Is it ok for sequence numbers to be re-used say
after the peer reboots?  I think you need to say. 

[Qin] See the above answer to #16, #18.


Regards!
-Qin
----- Original Message ----- 
From: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
To: <hokey@ietf.org>
Sent: Tuesday, November 22, 2011 2:39 AM
Subject: [HOKEY] AD review of draft-ietf-hokey-erp-aak


> 
> Hi all,
> 
> Here's my review of this. There are a lot of comments,
> but quite a few are very nitty or are things where I
> probably just need to be told that I don't know enough
> about ERP. (Which is true of course:-)
> 
> Some are non trivial however, and there are a lot of nits,
> so I've put this into the revised-ID-needed state.
> 
> Probably best is to handle any easy ones via email and
> then setup a skype chat for whatever's left. Let me
> know...
> 
> Cheers,
> S.
> 
>


--------------------------------------------------------------------------------


> _______________________________________________
> HOKEY mailing list
> HOKEY@ietf.org
> https://www.ietf.org/mailman/listinfo/hokey
>