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

Radia Perlman <radiaperlman@gmail.com> Thu, 09 February 2012 06:39 UTC

Return-Path: <radiaperlman@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 28C3C21F8599; Wed, 8 Feb 2012 22:39:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.686
X-Spam-Status: No, score=-3.686 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id JZHCKmlXwSwL; Wed, 8 Feb 2012 22:38:59 -0800 (PST)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 3361121F854E; Wed, 8 Feb 2012 22:38:59 -0800 (PST)
Received: by eaal12 with SMTP id l12so449735eaa.31 for <multiple recipients>; Wed, 08 Feb 2012 22:38:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=eftIdMBpfnNxikmImGG14w0pWLrQPM7vH2nLawK02W0=; b=W6NaeQjecH4Y5EJDvLbSLknqm9tabUaNHdyC6WLDoAZhbfxs3cAoInEkMePal3xb87 9HZc6CKqKrepx9ipPlDRBIyZ5vgBnjZbGgOvng5ARCZAbCE8W9ezCPJ8OsGq1AApFykP 4i3P29wTpNGSwfBifO2Qaac6ttHW+zfc2imQI=
MIME-Version: 1.0
Received: by with SMTP id m5mr162673ebc.62.1328769538328; Wed, 08 Feb 2012 22:38:58 -0800 (PST)
Received: by with HTTP; Wed, 8 Feb 2012 22:38:58 -0800 (PST)
Date: Wed, 8 Feb 2012 22:38:58 -0800
Message-ID: <CAFOuuo7Q-inZd_1cKqZAQF4B7mTkQTudu8txnrK2uH5QjMQgcQ@mail.gmail.com>
From: Radia Perlman <radiaperlman@gmail.com>
To: The IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-hokey-erp-aak.all@tools.ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [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 06:39:00 -0000

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

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.

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

There are various values that say TBD in the spec, but in the IANA
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.

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
or that the message is truncated to exclude that 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).

There's also lots of minor typos.  Should be proof-read.