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

Radia Perlman <> Thu, 09 February 2012 18:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ACD9021F865D; Thu, 9 Feb 2012 10:51:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.678
X-Spam-Status: No, score=-3.678 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t5rNdKvokII2; Thu, 9 Feb 2012 10:51:30 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 49EB921F865A; Thu, 9 Feb 2012 10:51:30 -0800 (PST)
Received: by eaal12 with SMTP id l12so674097eaa.31 for <multiple recipients>; Thu, 09 Feb 2012 10:51:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3T4Lj/eL6Ino3iBpBYYqh4VQf5TGd3zirfrZ5KkZodE=; b=IPLVvt1d0FvWdc7IZwqeEEwRN6wggC3KFsQpUPUYd4KM+uojeN8+6c7bSn1Blq+0dk QnUqz/37rgiFn7COUQp9T4Nyasn//Sl/22QC3nud16lWt8+evC8BCbgDYDm+6Hy87vt7 G+4NrClS1ISaqVfT8L1r0d+5mDpXmSyPne2ns=
MIME-Version: 1.0
Received: by with SMTP id p9mr569331ebc.138.1328813489339; Thu, 09 Feb 2012 10:51:29 -0800 (PST)
Received: by with HTTP; Thu, 9 Feb 2012 10:51:29 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Thu, 9 Feb 2012 10:51:29 -0800
Message-ID: <>
From: Radia Perlman <>
To: Qin Wu <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc:, The IESG <>,
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 18:51:31 -0000


>> 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.

I don't care which it is.  But the document has to specify.  I assume
when answering me, you were also going to specify it in the document.

>> 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?

That is somewhat significant text (not just a typo), but I assume
you'll get it right.