Re: [secdir] SECDIR review of draft-ietf-hokey-erp-aak
Qin Wu <bill.wu@huawei.com> Thu, 09 February 2012 10:26 UTC
Return-Path: <bill.wu@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6775121F86FD; Thu, 9 Feb 2012 02:26:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.895
X-Spam-Level:
X-Spam-Status: No, score=-5.895 tagged_above=-999 required=5 tests=[AWL=0.704, 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 vOp5kxsckMuB; Thu, 9 Feb 2012 02:26:17 -0800 (PST)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8E38921F86F2; Thu, 9 Feb 2012 02:26:17 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ4006KJFNJQ6@szxga03-in.huawei.com>; Thu, 09 Feb 2012 18:26:07 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ4009LWFNJKE@szxga03-in.huawei.com>; Thu, 09 Feb 2012 18:26:07 +0800 (CST)
Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGT09653; Thu, 09 Feb 2012 18:26:07 +0800
Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 09 Feb 2012 18:26:00 +0800
Received: from w53375q (10.138.41.130) by szxeml418-hub.china.huawei.com (10.82.67.157) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 09 Feb 2012 18:11:40 +0800
Date: Thu, 09 Feb 2012 18:11:38 +0800
From: Qin Wu <bill.wu@huawei.com>
X-Originating-IP: [10.138.41.130]
To: Radia Perlman <radiaperlman@gmail.com>, The IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-hokey-erp-aak.all@tools.ietf.org
Message-id: <0BD5C6E31FDC4BDC9813D221CD296680@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: <CAFOuuo7Q-inZd_1cKqZAQF4B7mTkQTudu8txnrK2uH5QjMQgcQ@mail.gmail.com>
X-Mailman-Approved-At: Thu, 09 Feb 2012 02:30:40 -0800
Subject: Re: [secdir] SECDIR review of draft-ietf-hokey-erp-aak
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Feb 2012 10:26:18 -0000
Hi, Radia: Thank for your valuable review. please see my replies inline. Regards! -Qin ----- Original Message ----- From: "Radia Perlman" <radiaperlman@gmail.com> To: "The IESG" <iesg@ietf.org>; <secdir@ietf.org>; <draft-ietf-hokey-erp-aak.all@tools.ietf.org> Sent: Thursday, February 09, 2012 2:38 PM Subject: SECDIR review of draft-ietf-hokey-erp-aak > have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This is mostly OK technically, but sloppily written. It's about giving a MH > the keys to a new access point after a handoff. > > Starting from section 3..."Peer" is sometimes called "MH" (mobile host). It's > preferable to use a single term, and I'd prefer MH (since it's not clear who > the MH is peer with in this protocol). [Qin]: Okay. We can use MH for terminology consistency. > > I found it surprising that the SAP knows where the MH will roam to. I'd think > that the MH would need to see a new CAP and tell its SAP who it wants to connect > with, or that the MH finds the CAP and tells the CAP who its SAP is/was. [Qin]: SAP doesn't know where the MH will roam to. But SAP knows which CAP is adjacent to itself and therefore SAP can provide the MH a list of CAPs which are all neighbor of that SAP via EAP-Initiate/Re-auth-Start message. Then MH can override CAP list carried in the EAP-Initiate/Re-auth-Start message and send a new CAP list using EAP-Initiate/Re-auth message to backend server through SAP. We can add some text to make this clear if you believe this addresses your concern. > Under figure 6, it says "The x flag is reserved. It MUST be set to 0". > Shouldn't the document say "and ignored on receipt"? [Qin]: Agree, will fix this by following your suggestion. Thanks. > There are various values that say TBD in the spec, but in the IANA > considerations, > there are values. So shouldn't they be copied into the spec instead of TBD? > Also, not all the TBD values are listed in the IANA considerations. [Qin]: Okay. > In the 4th paragraph before section 5.3, it talks about computing an integrity > checksum over the ERP/AAK packet, excluding the authentication tag field. > Does this mean that the authentication tag field is zeroed out for the > computation, > or that the message is truncated to exclude that field? [Qin]: I think it is the latter case. The integrity checksum over ERP/AAK packet is computed from the first bit of code field of packet to the last bit of cryptosuit field of the packet which is placed before authenticator tag field. > In the paragraph before section 5.3, it talks about silently discarding the > EAP-Initiate/Re-auth packet if it's not supported by the SAP. On a silent > discard, how long do you wait for a response before assuming there won't be any, > or perhaps that it got lost? (does it run over a reliable Transport? Even so, > it might be silently discarded). [Qin]: That's a good point. In the case of SAP initiating ERP/AAK, this is not a issue since SAP has already support ERP/AAK. In the case of Peer initiating ERP/AAK, the peer should maintain retransmission timer and maximum retransmission times. Based on retransmission timeout estimation, the peer can know there won't be any response. Does this address your comment? > There's also lots of minor typos. Should be proof-read. [Qin]: Okay, will fix this in the update. Thanks. > Radia