[HOKEY] AD review of draft-ietf-hokey-arch-design

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sun, 23 October 2011 16:52 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: hokey@ietfa.amsl.com
Delivered-To: hokey@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7C90F21F8A95 for <hokey@ietfa.amsl.com>; Sun, 23 Oct 2011 09:52:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.599
X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id uw3S2xp9JQqj for <hokey@ietfa.amsl.com>; Sun, 23 Oct 2011 09:52:25 -0700 (PDT)
Received: from scss.tcd.ie (hermes.cs.tcd.ie []) by ietfa.amsl.com (Postfix) with ESMTP id 7823721F84D2 for <hokey@ietf.org>; Sun, 23 Oct 2011 09:52:25 -0700 (PDT)
Received: from localhost (localhost []) by hermes.scss.tcd.ie (Postfix) with ESMTP id 120EC154077 for <hokey@ietf.org>; Sun, 23 Oct 2011 17:52:23 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-type:subject:mime-version:user-agent:from:date :message-id:received:received:x-virus-scanned; s=cs; t= 1319388742; bh=K0nmfYM9LHltzfZYWTa73hKASQ/1kFgp9u5e109ardU=; b=h Qug/w31s+xMPkTL5k8z58XTRkddecZKnRKf3rYo7OmczbrAdK1Z0qA19BxE6G9g6 LWxNXji+VS66dba58OSnSMTpbfuXchvl6bSL9f5yoyAhvuGziTjRMnuU05tHOhx0 PwHvKmuRQfJfBr4wp6POdpEEaFuKguY9QIiiFVt9ui/uGL6bVJd+EC2fVxx/OjyD 6J0aRV/z8c4DT7b3vr5zCyYcygc+iMD6Bpz8VAJo6UP/bzdT3FmJ9B3v0umLuHJ1 QQ4L30XoQxHMi/eHWEu96nPGsciIcHJrXtOtHVJWqCnqSY7Hfz+6ckEzmtsYug5C A0R7/ykr7YA3pk9myQ42Q==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([]) by localhost (scss.tcd.ie []) (amavisd-new, port 10027) with ESMTP id Db8+eivPzC4r for <hokey@ietf.org>; Sun, 23 Oct 2011 17:52:22 +0100 (IST)
Received: from [] (unknown []) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6369415364A for <hokey@ietf.org>; Sun, 23 Oct 2011 17:52:22 +0100 (IST)
Message-ID: <4EA4463B.6000304@cs.tcd.ie>
Date: Sun, 23 Oct 2011 17:52:11 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: hokey@ietf.org
Content-Type: multipart/mixed; boundary="------------040907040201050802090008"
Subject: [HOKEY] AD review of draft-ietf-hokey-arch-design
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: Sun, 23 Oct 2011 16:52:31 -0000

Hi all,

I've had a look at this and have a couple of questions (below) I'd
like to chat about before mving this forward to IETF LC.

I've also a couple of questions for which I'd be interested in
the answers and a load of nits, (in the attached file) but I'm
happy for all but the two below to be handled with any other IETF
LC feedback.

So my questions:

1) I was hoping this document might help me understand ways in which
candidate access points might be identified. It didn't though. Was it
supposed to tell me that?  If not, then what would tell me that?
(Maybe there is, or is not, a change needed for this, I don't know

2) Section 9 doesn't do it for me, sorry;-) Two possibilities -
either you argue convincingly that its ok as-is (in mail and then the
PROTO write up please) or else you try to address/reference generic
hokey security considerations.  I'd prefer the latter, as I'd
otherwise expect the current empty section 9 to generate DISCUSSes if
nothing's done. The ones that occur to me that might not be elsewhere
would include: a) hokey implies moving more keys about in various new
ways, summarise the argument that none of these are leaking key bits,
b) AAK seems to have a potential DoS if e.g.  someone causes AAK to
be done with loads of CAPs, or loads of AAK with one CAP, and maybe
c) if someone chooses the wrong CAP then they might have been fooled
into sending all the user's traffic via a bad actor. There could also
be more of course, but that's what occurs to me. Note that I think a
sentence or two on each with a pointer to the RFC where its further
discussed would be fine if there's such an RFC.  (I think tihs does
need a change, and I'm reluctant to be convinced otherwise, but its
possible if you wanna try.)