Re: [secdir] SECDIR review of draft-ietf-hokey-erp-aak

Qin Wu <> Thu, 09 February 2012 10:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6775121F86FD; Thu, 9 Feb 2012 02:26:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.895
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vOp5kxsckMuB; Thu, 9 Feb 2012 02:26:17 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8E38921F86F2; Thu, 9 Feb 2012 02:26:17 -0800 (PST)
Received: from (szxga03-in []) by (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <>; Thu, 09 Feb 2012 18:26:07 +0800 (CST)
Received: from ([]) by (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <>; Thu, 09 Feb 2012 18:26:07 +0800 (CST)
Received: from ([]) by (MOS 4.1.9-GA) with ESMTP id AGT09653; Thu, 09 Feb 2012 18:26:07 +0800
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 09 Feb 2012 18:26:00 +0800
Received: from w53375q ( by ( 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 <>
X-Originating-IP: []
To: Radia Perlman <>, The IESG <>,,
Message-id: <>
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: <>
X-Mailman-Approved-At: Thu, 09 Feb 2012 02:30:40 -0800
Subject: Re: [secdir] SECDIR review of draft-ietf-hokey-erp-aak
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.

----- Original Message ----- 
From: "Radia Perlman" <>;
To: "The IESG" <>;; <>;; <>;
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