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

Stephen Farrell <> Sat, 29 October 2011 14:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 299FB21F8906 for <>; Sat, 29 Oct 2011 07:53:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.049
X-Spam-Status: No, score=-102.049 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, GB_ABOUTYOU=0.5, J_CHICKENPOX_12=0.6, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w9e0IdtIcNbw for <>; Sat, 29 Oct 2011 07:53:29 -0700 (PDT)
Received: from ( [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by (Postfix) with ESMTP id 2F72721F88B6 for <>; Sat, 29 Oct 2011 07:53:28 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E44815358E; Sat, 29 Oct 2011 15:53:27 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1319900006; bh=N4GGKSDHnujZlz SUCBdakxX43S/ahiVm5jXUY7eyhHQ=; b=IN0MGiBAznYWyUwrXxHyNMuQigHo79 KChQhs6GxQ2tRJpRIsDesPiNspECtfSczwoyCN5DNqliOTLEeq2eCaRmLdCpxheE FCR8zuA1g4ynDVMVtLZQjfLGBTC5fow+6EhQ8zqRsaG/8j0oR0LHUNptSUwGZGYp PMYTi4zZwhIAJf7QW5BUVoIntA1hb1SSIvxqklZGLA99pYagy5mZbLJ2Zx3tEyzm HuKPGAfr+HHOW/aq2P3J1zUkndNFVXHy3cuNs5Xne4uKt0AAyQG2Z3npp51B/GoL kYOIfgWGF3EZBgyVmHMfzfcz46uMPUGtc+Z9Bwml8rwWe98ul1UfRURg==
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10027) with ESMTP id 5Gp1f6JKZsyv; Sat, 29 Oct 2011 15:53:26 +0100 (IST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id F1C3E15358D; Sat, 29 Oct 2011 15:53:25 +0100 (IST)
Message-ID: <>
Date: Sat, 29 Oct 2011 15:53:24 +0100
From: Stephen Farrell <>
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: Glen Zorn <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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:53:30 -0000

Hi Glen,

On 10/29/2011 03:29 PM, Glen Zorn wrote:
> 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.
> Sorry!
>> It didn't though.
> Nope.
>> 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.)

Ok, thanks. It'd have helped me if it'd said that somewhere but if
you tell me that the real readership would know all that then I'm
ok with that.

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

Ok, so we're not in agreement here. But not that far apart either

>> I'd prefer the latter, as I'dk
>> 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.

What's wrong with saying that in the sec. cons. of the document or
the PROTO write up? I think its a good thing to know and that the
architecture doc is a good place to tell the reader.

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

Ok. See below.

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

Doesn't hokey make the client believe its implicitly
authenticated the CAP? Is that really the same as any old

Anyway, if you do think that's the case, this is also a good
thing to say in the document or PROTO write up.

> I'm kind of opposed
> to solving all the world's problems here...

Of course. Me too.

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

How's about you add your reactions to a) and c) either to the
doc or PROTO write up and we treat b) along with any other IETF
LC feedback received?


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