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

Glen Zorn <> Sat, 29 October 2011 14:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C026321F84D6 for <>; Sat, 29 Oct 2011 07:29:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.46
X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id x5riZaq6b2gN for <>; Sat, 29 Oct 2011 07:29:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7C8EE21F84CD for <>; Sat, 29 Oct 2011 07:29:31 -0700 (PDT)
Received: by ywt2 with SMTP id 2so5375340ywt.31 for <>; Sat, 29 Oct 2011 07:29:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=igDwuqfLNsPCNexRnTfUilNfa4RXhcjwdPXfwVZoHbY=; b=dVPZY4/Z4prgNNA/vWCB1ulZJkWQzGfDYETNmipyvW2EC5nZuvVi/1ZU+M8FdEYjhi YnJBxh3/hEy2hksLlyLr4nXlolrRaRlEzt22f4r9uxyr6HgaWUqqyFE/1zZqx88zE54h P4y6R4KQowpzfHQ2nxqPHNRjgmBucZre5Iltk=
Received: by with SMTP id h10mr10958102pbv.13.1319898570194; Sat, 29 Oct 2011 07:29:30 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id 4sm33149582pbj.18.2011. (version=SSLv3 cipher=OTHER); Sat, 29 Oct 2011 07:29:28 -0700 (PDT)
Message-ID: <>
Date: Sat, 29 Oct 2011 21:29:20 +0700
From: Glen Zorn <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Stephen Farrell <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [HOKEY] AD review of draft-ietf-hokey-arch-design
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: HOKEY WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 29 Oct 2011 14:29:37 -0000

On 10/23/2011 11:52 PM, Stephen Farrell wrote:
> 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?  

Nope, that is specifically out of scope.

> If not, then what would tell me that?

Possibly one of the many documents available from the WiMAX Forum, 3GPP,
3GPP2, IEEE, etc.  That's why it was deemed out of scope: the whole CAP
discovery & selection thing is very specific to the lower layer in use.

> (Maybe there is, or is not, a change needed for this, I don't know
> yet.)
> 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 think that it's pretty much OK as-is.

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

Actually, it does & it doesn't: a couple of new keys are derived, but
the way in which they are moved and the types of entities between which
they are transferred are just the same as with regular old EAP: AAA,
authenticators & authentication servers.  Basically, if EAP/AAA is OK
(which I admit is questionable) then hokey's OK, too.

> 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

I need to think about this a bit: I'm pretty sure that that is the case
w/regular EAP as well, but if I remember correctly 802.11 has a defense
against that; since AAK doesn't have a L@ to rely upon for such things,
maybe it should supply it.  Or maybe not.

> c) if someone chooses the wrong CAP then they might have been fooled
> into sending all the user's traffic via a bad actor. 

Again, that is not specific to hokey, re-authentication or mobility: any
WiFi AP to which one connects could be a bad actor.  I'm kind of opposed
to solving all the world's problems here...

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

There you go ;-)

> Cheers,
> Stephen.
> _______________________________________________
> HOKEY mailing list